| 01:15 | <sephr> | is there such a thing as `CustomEvent document.customEvent(...)`? |
| 01:15 | <sephr> | I just noticed that on MDN https://developer.mozilla.org/en/DOM/customEvent and it looks like someone just made up the page |
| 01:31 | <heycam> | sephr, I don't think that page is accurate |
| 01:31 | <heycam> | no such thing as document.customEvent in Gecko afaict |
| 01:31 | <sephr> | yeah I think someone messed up |
| 01:31 | <sephr> | I'm moving the page to Event/CustomEvent fixing the docs now |
| 01:32 | <heycam> | cool, thanks |
| 01:38 | <sephr> | heycam: speaking of events, does initStorageEvent actually modify dom storage? |
| 01:38 | <sephr> | I would think it doesn't |
| 01:38 | sephr | is trying to base the new customevent page off the storageevent one |
| 01:41 | <heycam> | sephr, no, it should just initialise the event object |
| 01:41 | <heycam> | sephr, shouldn't have any other effect |
| 01:42 | <sephr> | k thanks |
| 03:26 | <Hixie> | abarth: not trying to troll them. It's just frustrating that they don't understand the difference between RDFa and microdata. The very thing they keep saying is the problem with microdata is the reason microdata is giving them a problem in the first place. |
| 03:26 | <abarth> | i like the comparison between the pencil and the industrial laser printer |
| 03:27 | <abarth> | "RDFa: A horribly-designed technology that..." |
| 03:27 | <abarth> | that's the part that sounds trollish |
| 03:30 | <Hixie> | I previously had assumed that RDFa was a well-designed technology to address a problem I didn't understand. |
| 03:31 | <Hixie> | But Manu has been insistent in telling me that I am wrong, that RDFa was designed to address a specific set of use cases. |
| 03:31 | <Hixie> | well given those use cases, I really don't know how else to characterise RDFa but "horribly-designed". |
| 05:12 | <Hixie> | wow: https://plus.google.com/u/0/112095156983892490612/posts/BSShqcMm49B |
| 05:12 | <Hixie> | at least on xforms person _still_ doesn't understand to this day what the backwards-compatibility issue is |
| 09:02 | <jgraham> | foolip: hg export might be what you are looking for |
| 09:02 | <foolip> | jgraham, thanks, looks like it is! |
| 09:12 | <foolip> | jgraham, you're not CC:d on the bug, are the mails sent to some list? |
| 09:14 | <jgraham> | foolip: No, I just followed your link |
| 09:14 | <foolip> | eh, stupid me :) |
| 09:15 | <foolip> | 1. announce 2. forget 3. surprise at attention |
| 12:10 | <Ms2ger> | So, is anybody going to register rel=disclosure or are we going to keep all W3C specs invalid? |
| 13:34 | <jgraham> | Ms2ger: Is there a spec for it? |
| 13:34 | <Ms2ger> | Not one I managed to find |
| 13:34 | <Ms2ger> | Isn't "mentioned in pubrules" enough? |
| 15:00 | <AryehGregor> | smaug____, pong. |
| 15:00 | <AryehGregor> | [110722 10:32:42] <AryehGregor> smaug____ (who isn't here): the draft doesn't have to special-case replaceData/appendData because when it was written, those just called insertData/deleteData. Now annevk has rewritten that in DOM Core at my request, and I'll rewrite the Range stuff soon to work with the new wording. As for splitText, see the comments in the spec's HTML source. IIRC, I copied the behavior from WebKit, who made it up; it make |
| 15:00 | <AryehGregor> | s a lot of sense, and IIRC roc t |
| 15:00 | <AryehGregor> | [110722 10:32:42] <AryehGregor> hought it was a good idea. Without that special-case I'd have to add a bunch of different execCommand() special-cases, so it's no simpler, and authors don't get the improved behavior. |
| 15:01 | <AryehGregor> | Double-wrapping :( |
| 15:04 | <smaug____> | AryehGregor: yeah, I haven't yet quite decided which behavior for splitText makes most sense |
| 15:05 | <AryehGregor> | It's a tradeoff between simplicity and doing what makes sense in the specific case. |
| 15:05 | <smaug____> | for consistency the new spec is bad, but I could see the new spec more useful for web devs |
| 15:05 | <AryehGregor> | Without a special case for splitText, range mutation will do the wrong thing every time for it. |
| 15:05 | <smaug____> | wrong? |
| 15:05 | <AryehGregor> | As in unexpected, not what the author intended. |
| 15:06 | <smaug____> | it would do what is logical, IMHO |
| 15:06 | <AryehGregor> | And as I said, the added special case here removes multiple special cases elsewhere, so IMO it's an overall win for simplicity. |
| 15:06 | <AryehGregor> | Only if you view splitText as performing a sequence of DOM operations that involves deleting some text from one node and then creating an entirely unrelated node. |
| 15:06 | <AryehGregor> | If you view it as actually splitting an existing node, which is what it does intuitively and what the name implies, the non-special-case behavior makes no sense at all. |
| 15:07 | <AryehGregor> | E.g., it would be impossible to predict which node the range remained in, unless you knew which node the method happens to add (first vs. second). |
| 15:07 | <AryehGregor> | Which I'm not absolutely confident I remember, in fact, although I'm pretty sure it keeps the first node and adds the second. |
| 15:08 | <AryehGregor> | But if I have to think about it, your average web author stands no chance at all. |
| 15:08 | <AryehGregor> | (granted that which node is added is already visible in that that's the one it returns, but it's still not the way anyone's going to actually think of it working) |
| 15:08 | <smaug____> | it is just very surprising that DOM mutations can change range.start/endNode |
| 15:09 | <AryehGregor> | Only if you're thinking about things at a very low level. |
| 15:09 | <smaug____> | er, start/endContainer |
| 15:09 | <smaug____> | not really low level |
| 15:09 | <AryehGregor> | If you're thinking about things from a high level, what's surprising is when calling a method like splitText that has no visual effect at all in normal circumstances makes half the user's selection disappear. |
| 15:10 | <smaug____> | you attach the range to some text node, and suddenly it is moved to some other node |
| 15:10 | <smaug____> | that is surprising |
| 15:10 | <AryehGregor> | No, you select some visible text and suddenly half your selection disappears even though the text is plainly still there. *That's* surprising. |
| 15:11 | <AryehGregor> | It just so happens that the selection of text is implemented in terms of a DOM with Nodes and Ranges and stuff, but that's not what anyone's going to base their expectations on unless they're a real JS guru. |
| 15:11 | <smaug____> | in that case the js code shouldn't use splitText, but modify the text data directly |
| 15:11 | <smaug____> | but as I said, I'm not yet quite sure which approach I prefer... |
| 15:12 | <smaug____> | usually I'm all for consistency, but in this case inconsistent behavior might be ok |
| 15:13 | <AryehGregor> | How can it modify the text data directly and achieve the desired effect? |
| 15:13 | <AryehGregor> | Manually resetting the selection? |
| 15:14 | <AryehGregor> | That's what execCommand() largely does, but it's extra work and it breaks other Ranges people might be using for other purposes (e.g., if some script saved the selection and wants to restore it later). |
| 15:14 | <smaug____> | ah, right, the case when insertNode(someelement) is called on text node |
| 15:15 | <smaug____> | I was thinking about insetNode(sometextnode) |
| 15:17 | <AryehGregor> | What about it? |
| 15:19 | <smaug____> | for insertNode(sometext) js should usually just modify the text data |
| 15:19 | <smaug____> | s/for/instead of/ |
| 15:20 | <AryehGregor> | We're talking about splitText, no? When did the conversation shift to insertNode? |
| 15:20 | <AryehGregor> | I assume that if you're insertNode()ing a Text node into a Text node, it's only because you're writing a generic algorithm that's meant to handle multiple different types of nodes. |
| 15:20 | <AryehGregor> | It would be pretty silly to not just use insertData(), otherwise. |
| 15:22 | <smaug____> | insertNode does splitText |
| 15:22 | <AryehGregor> | As do many other things, yeah. |
| 15:26 | <smaug____> | I really wish specs had some annotation to indicate why something is defined as it is |
| 15:27 | <smaug____> | especially specs which aren't written based on bugs in some tracker/bugzilla |
| 15:28 | <espadrine> | smaug____: something like perl6's Apocalypses and Exegesis? Yes, that can help |
| 15:29 | <AryehGregor> | smaug____, I put it in comments in the HTML source. |
| 15:29 | <AryehGregor> | There are some really long detailed comments in the specs I edit. |
| 15:29 | <AryehGregor> | Sometimes a hundred lines long or more. |
| 15:29 | <AryehGregor> | (in at least one extreme case) |
| 15:30 | <smaug____> | ah, need to just make those visible to the reader |
| 15:36 | <AryehGregor> | I could, but they can get very long. |
| 15:36 | <AryehGregor> | In plenty of cases I have multiple paragraphs of discussion for a single line of spec text. |
| 15:36 | <AryehGregor> | Maybe comments aren't the best way to do that, but having it inline doesn't seem great either. |
| 15:36 | <AryehGregor> | Hmm, I should have it inline but collapsed using JS. |
| 15:36 | <AryehGregor> | (or <details>, if anyone supports that properly yet) |
| 15:36 | <AryehGregor> | That would be ideal. |
| 15:49 | <TabAtkins_> | AryehGregor: <details> works in Chrome now. |
| 15:50 | <AryehGregor> | TabAtkins_, do you know of a good JS shim? |
| 15:50 | <AryehGregor> | Also, it seems like the Chrome implementation forces the <details> to its own line, which I don't want. |
| 15:50 | <AryehGregor> | When I do style=display:inline, it doesn't do anything. |
| 15:50 | <AryehGregor> | Oh, wait. |
| 15:51 | <AryehGregor> | I was trying to put it inside a <p>. |
| 15:51 | AryehGregor | tries again |
| 15:51 | <TabAtkins_> | AryehGregor: Also maybe put display:inline on the summary too. |
| 15:51 | <AryehGregor> | Seems to work if I put it in an <li> or something. |
| 15:51 | <AryehGregor> | That's bad, though, I want to put it in <p>. |
| 15:51 | <TabAtkins_> | Blame Hixie. |
| 15:52 | <TabAtkins_> | He didn't want <p>'s autoclose behavior to be inconsistent. |
| 15:52 | <AryehGregor> | Hmm. |
| 15:52 | AryehGregor | files a bug |
| 15:54 | <TabAtkins_> | For JS shim, I guess check out Paul Irish's master list of shims. |
| 15:54 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=13345 |
| 15:54 | AryehGregor | e-mails Hixie a link to the bug |
| 15:55 | <AryehGregor> | (to request prioritization, since it affects existing new implementations and we don't have much time to change the behavior if we're going to do so) |
| 15:55 | <TabAtkins_> | Hmm, making it inline by default is interesting. Makes sense for the spec use-case. |
| 15:55 | TabAtkins_ | wants to use it for all his notes and issues now. |
| 16:02 | <AryehGregor> | Most notes/issues shouldn't be collapsed, IMO. |
| 16:02 | <AryehGregor> | Rationale should be. |
| 16:42 | <AryehGregor> | Also maybe some todo's. |
| 16:46 | <hsivonen> | foolip: there's no support in the build script for not pulling the w3.org DTD. (hooray for w3.org DTDs!) |
| 17:26 | <AryehGregor> | Apparently IE10PP2 isn't using a fully compliant HTML parser . . . <font color=#ABCDEF> becomes <font color=#abcdef> in the DOM. |
| 17:28 | <annevk> | oops |
| 17:51 | <AryehGregor> | hsivonen, do the parser tests test that <font color=#ABCDEF> doesn't get parsed to <font color=#abcdef>? If not, could we add such a test? |
| 17:56 | <ruediger> | hi |
| 17:56 | <AryehGregor> | Hi! |
| 18:01 | <AryehGregor> | Actually, IE is much more egregious. |
| 18:01 | <AryehGregor> | It turns <span style=color:#aBcDeF> into <span style="color: rgb(171, 205, 239);"> too. |
| 18:01 | <AryehGregor> | It's not the only one that does weird stuff. |
| 18:02 | <AryehGregor> | Gecko adds tabindex="0" to <video>. |
| 18:02 | <AryehGregor> | Always. |
| 18:02 | <AryehGregor> | Like, wtf? |
| 18:02 | <ruediger> | does the html5 wg accept new named character references? (section 8.5 in the html5 spec) I'd like to propose &Szlig; for capital ß http://en.wikipedia.org/wiki/Capital_%C3%9F |
| 18:03 | <AryehGregor> | hsivonen, do the parser tests include basic sanity checks to make sure browsers aren't randomly mangling attributes, or is it mostly focused on ensuring that everything gets the right parents and such? |
| 18:03 | <hsivonen> | AryehGregor: IIRC, they don't test that and you are welcome to contribute tests under the MIT license that html5lib uses |
| 18:03 | <annevk> | ruediger, the Math WG is in charge of entities |
| 18:03 | <annevk> | ruediger, and they have not been expanded since 98 practically |
| 18:04 | <annevk> | ruediger, just use the character like you did here |
| 18:04 | <AryehGregor> | ruediger, we probably are not going to add new named entities for things that are sufficiently obscure that they were only added in Unicode 5.1. |
| 18:04 | <AryehGregor> | Actually, we're probably not going to add many new named entities at all. |
| 18:04 | <AryehGregor> | Just encode it as UTF-8. |
| 18:04 | <ruediger> | annevk: yeah, normally I don't bother with named characters and use utf8. But for the sake of consistency |
| 18:05 | <hsivonen> | https://twitter.com/#!/daaitoulaam/status/94988135091535873 |
| 18:05 | <ruediger> | lower case ß is supported as ß |
| 18:05 | <AryehGregor> | hsivonen, where's the right place to look at and submit new parser tests? |
| 18:06 | <annevk> | ruediger, you can raise it as a bug; the relevant math people will prolly cc themselves |
| 18:06 | <annevk> | ruediger, he's in this channel as david_carlisle |
| 18:06 | <ruediger> | thanks |
| 18:07 | <ruediger> | I'll do that |
| 18:07 | <hsivonen> | AryehGregor: http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata |
| 18:08 | <annevk> | hsivonen, you retweet that he calls you an utter ass? |
| 18:09 | <annevk> | @gruber-style :p |
| 18:09 | <AryehGregor> | hsivonen, and those are being made part of the official HTML5 test suite at this point, or what? |
| 18:09 | <hsivonen> | annevk: yeah, that was a @gruber-style retweet--not a retweet implying agreement |
| 18:10 | <hsivonen> | AryehGregor: dunno about Official, but that's the set of test parser devs pay attention to |
| 18:10 | <AryehGregor> | hsivonen, are they runnable cross-browser by just visiting a web page? |
| 18:10 | <hsivonen> | AryehGregor: not to my knowledge, but my knowledge may be stale |
| 18:11 | <AryehGregor> | Hmm, okay. |
| 18:12 | <hsivonen> | AryehGregor: jgraham probably knows more about the cross-browser harness situation |
| 18:12 | <AryehGregor> | jgraham, do you know what the story is with cross-browser parser tests, and their status as Official W3C Tests(tm)? |
| 18:12 | <annevk> | adding <video>, something with a style attribute and such does make sense |
| 18:13 | <AryehGregor> | I'd add at least one example of every element/attribute combination, ideally. |
| 18:13 | <AryehGregor> | Of course, I like my tests to be thorough. |
| 18:13 | <AryehGregor> | Also, make sure to test corner cases for all of them, including leading and trailing whitespace, special characters, etc. |
| 18:14 | <AryehGregor> | There should be no special per-attribute value mangling at the parser level at all, AFAIK. |
| 18:14 | <AryehGregor> | Definitely not stuff like reserializing style attributes. |
| 18:15 | <annevk> | correct |
| 18:17 | <AryehGregor> | Or adding tabindex="0". |
| 18:17 | <AryehGregor> | Or stripping leading/trailing whitespace from URL attributes (I caught Gecko doing that even with setAttribute(), but I filed a bug and they fixed it). |
| 18:18 | <hsivonen> | AryehGregor: adding tabindex="0" is not a parser bug, FWIW, but it's a bug exposed by parser tests |
| 18:19 | <hsivonen> | (of course, if you are testing the whole box, you shouldn't care which part of it gets the blame) |
| 18:20 | <AryehGregor> | Hmm, using appendChild creates it too. |
| 18:20 | <AryehGregor> | Fun. |
| 18:27 | <hsivonen> | I wonder how the "This user" badges for Wikipedia user pages started |
| 18:28 | <AryehGregor> | You mean the userboxes? |
| 18:28 | <AryehGregor> | Somebody made one up for fun because they were bored, probably in like 2003 or something. |
| 18:29 | <hsivonen> | AryehGregor: I meant {{user foo}} boxes |
| 18:29 | <AryehGregor> | The Babel boxes, for languages? Like {{user en}}? |
| 18:29 | <AryehGregor> | Oh, other userboxes also often start with "User ". |
| 18:29 | <AryehGregor> | Anyway, yeah, those are userboxes. |
| 18:30 | <AryehGregor> | Actually, I think Babel boxes may have been first, just for practical reasons. |
| 18:30 | <AryehGregor> | Then people had fun with it and made all sorts of stupid random useless ones. |
| 18:30 | <hsivonen> | AryehGregor: I mean "This user would like to own one or more dogs." |
| 18:30 | <AryehGregor> | Yeah, userboxes. |
| 18:30 | <AryehGregor> | At some point there was a purge and the more frivolous ones were moved out of Template: namespace into individual users' namespaces. |
| 18:31 | <AryehGregor> | http://en.wikipedia.org/w/index.php?title=Template:Userbox&oldid=18039616 |
| 18:31 | <AryehGregor> | There were probably earlier uses using other templates, though, or just ad hoc stuff. |
| 18:32 | <AryehGregor> | http://en.wikipedia.org/w/index.php?title=Template:User_en&oldid=11184536 |
| 18:33 | <hsivonen> | AryehGregor: my humor detector is dysfunctional with some of these |
| 18:34 | <hsivonen> | AryehGregor: that is, I can't tell which ones are serious and which ones an inside wiki meta humor |
| 18:35 | <hsivonen> | s/an/are/ |
| 18:43 | <david_carlisle> | ruediger: I was away from my machine, but as they said we don't normally add new names just on consistency grounds, For example only the letters have entity names for open facem even though Unicode added digits as well in the end, see http://www.w3.org/2003/entities/2007doc/double-struck.html |
| 18:45 | <ruediger> | david_carlisle: :-/ but thanks for your reply |
| 18:49 | <david_carlisle> | ruediger: seem the bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=13108#c2 which is a requested name with slightly different issues, but possibly the same outcome (although that bug isn't closed yet) |
| 19:18 | <jgraham> | AryehGregor: http://w3c-test.org/html/tests/submission/Opera/html5lib/ |
| 19:18 | <jgraham> | That needs to be updated a little, but it is only a few commits behind |
| 19:19 | <AryehGregor> | jgraham, in Chrome 14 dev, with "Test with document.write" and "Run All Tests", it stops after a little while with "test.js:239Uncaught ReferenceError: template is not defined" |
| 19:21 | <jgraham> | Oh, that may be one of the things that needs to be updated :) |
| 19:22 | <AryehGregor> | I get security errors when trying to use data: URLs, too. |
| 19:22 | <jgraham> | I thought I pushed that change to the W3C copy already, but maybe I only did the Opera-internal copy |
| 19:22 | <jgraham> | Yeah, Chrome won't let you read the DOM of a data URI loaded in an iframe |
| 19:22 | <jgraham> | AFAICT this is dumb and chrome should allow it |
| 19:27 | AryehGregor | concurs |
| 19:29 | <AryehGregor> | abarth, why does Chrome not allow reading the DOM of a data URL loaded in an iframe? |
| 19:29 | <annevk> | there's an open bug on that I think |
| 19:30 | <TabAtkins_> | AryehGregor: Because we don't handle origins correctly, I believe. |
| 19:30 | <TabAtkins_> | (The spec makes it clear that it should be same-origin.) |
| 19:30 | <AryehGregor> | So it's not intentional, in other words? |
| 19:30 | <AryehGregor> | Ah, okay. |
| 19:30 | <AryehGregor> | So just a bug. |
| 19:33 | <annevk> | http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/thread.html#msg79 reference mania strikes again |
| 19:33 | <abarth> | AryehGregor: because you haven't sent WebKit a patch that fixes that bug yet :) |
| 19:34 | <abarth> | AryehGregor: its a tricky bug to fix, which is why no one has sent us a patch yet |
| 19:48 | <AryehGregor> | Oh, Opera doesn't implement Object.keys? Lame. |
| 19:49 | <AryehGregor> | As of 11.50. |
| 19:49 | <AryehGregor> | Isn't that part of ES5, and haven't all the cool kids implemented ES5 by now? |
| 19:50 | <karlcow> | AryehGregor: ES5 is not implemented yet in a released version of Opera |
| 19:50 | AryehGregor | works around it |
| 19:54 | <annevk> | I wonder when dev.w3.org will move to hg |
| 19:55 | <jgraham> | annevk: Remind me, when is the heat death of the universe again? |
| 19:57 | <Dashiva> | Next Thursday |
| 20:00 | <annevk> | jgraham, tralala |
| 20:00 | <jcranmer> | Dashiva: already? |
| 20:01 | <jcranmer> | damn, better hurry up if I want to finish some things before the universe dies |
| 20:15 | <karlcow> | hsivonen: re: identity… it is also a bit like leaving your passport for the length of your visit to the local police. |
| 20:16 | <TabAtkins_> | Hixie: I can't find the diff where you added the :ltr and :rtl pseudos. Halp? |
| 20:26 | <Hixie> | TabAtkins_: please hold |
| 20:26 | <Hixie> | r5672? |
| 20:26 | <Hixie> | $ grep :ltr blame.r6000 5672 ianh <dt><dfn title="selector-ltr"><code>:ltr</code></dfn></dt> 5672 ianh <p>The <code title="selector-ltr">:ltr</code> pseudo-class must 5672 ianh :ltr { direction: ltr; } |
| 20:26 | <Hixie> | well |
| 20:26 | <Hixie> | er |
| 20:26 | <Hixie> | the spacing in that paste went all to hell |
| 20:26 | <Hixie> | but anyway |
| 20:26 | <Hixie> | if you need blame files i have files called blame.rXXXX in the spec directory |
| 20:26 | <Hixie> | for various values of XXXX: |
| 20:26 | <Hixie> | blame.r0005 blame.r0500 blame.r1000 blame.r2200 blame.r2500 blame.r2905 blame.r3000 blame.r4000 blame.r5000 blame.r5600 |
| 20:26 | <Hixie> | blame.r0050 blame.r0954 blame.r2000 blame.r2216 blame.r2800 blame.r2947 blame.r3075 blame.r4667 blame.r5287 blame.r6000 |
| 20:26 | <Hixie> | hth |
| 20:33 | <AryehGregor> | Sounds like a workaround for svn blame being unreasonably slow. |
| 20:33 | <AryehGregor> | git blame takes like thirty seconds max on big repos for me . . . although granted I haven't tried it with a repo that mostly consists of one huge file that's changed in every commit. |
| 20:34 | <Philip`> | Does git blame provide any way to discover what revision a line was removed in? |
| 20:34 | <AryehGregor> | I'm pretty sure it does, but I haven't ever tried. |
| 20:37 | <Philip`> | Ah, looks like it has a --reverse option |
| 20:37 | <AryehGregor> | git commands have seldom been faulted for having an insufficient number of options. |
| 20:38 | Philip` | has occasionally wanted a feature like that, since in SVN/etc it's much more annoying to have to do a manual binary search than having to wait a few minutes while a normal blame runs in the background |
| 20:38 | <AryehGregor> | "JSON.parse: unexpected keyword" |
| 20:38 | <AryehGregor> | What could that possibly mean? |
| 20:39 | <AryehGregor> | Firebug is reporting it for the line "test = JSON.parse(test);". |
| 20:39 | <AryehGregor> | Oh, it must mean there's an error in the input. |
| 20:39 | <AryehGregor> | I.e., the test variable isn't valid JSON. |
| 20:39 | <AryehGregor> | That confused me. |
| 20:49 | <Hixie> | AryehGregor: that's exactly what it is :-( |
| 20:50 | <Hixie> | AryehGregor: last time i heard of someone trying to put the spec in git, the migrate crashed or something. |
| 20:50 | <AryehGregor> | Hmm. |
| 20:50 | <AryehGregor> | It's true that git doesn't like very large files, but the spec should be small enough, I'd think. |
| 20:50 | <Hixie> | 5MB * 6000 revisions? :-) |
| 20:51 | <AryehGregor> | What's the SVN checkout URL, just http://svn.whatwg.org/webapps/? |
| 20:51 | <Hixie> | i believe so |
| 20:51 | <jgraham> | I have it in git |
| 20:51 | <Hixie> | ah, cool |
| 20:51 | <jgraham> | The problem was mirroring it to github |
| 20:51 | <Hixie> | aah |
| 20:52 | <jgraham> | The import was slow and timed out or something |
| 20:52 | <AryehGregor> | How fast is a blame? |
| 20:52 | AryehGregor | tries git svn clone http://svn.whatwg.org/webapps/ |
| 20:54 | <AryehGregor> | git was designed for use by the Linux kernel, the number of revisions you have is trivial. |
| 20:55 | <AryehGregor> | As is overall repo size. |
| 20:55 | <AryehGregor> | I doubt 5M in one file is a big problem either. |
| 20:55 | <AryehGregor> | I had problems when I tried using it for incremental backup of a database; apparently it doesn't like multi-gigabyte files (tries to read them entirely into memory). |
| 20:55 | <AryehGregor> | But 5M should be no problem. |
| 20:55 | <AryehGregor> | It's worth switching from svn to git just for the speed . . . |
| 20:56 | <jgraham> | Either I got the blame syntax wrong or it is not all that fast in this case |
| 20:57 | <AryehGregor> | It's usually not super-fast, it does have to read the whole history off disk. |
| 20:57 | <AryehGregor> | Well, not the whole history. |
| 20:57 | <AryehGregor> | But it's ridiculously faster than svn blame. |
| 20:58 | <jgraham> | Well yes I wouldn't even try this with svn |
| 20:59 | <jgraham> | If someone mirrored the spec to something with a reasonable diff viewer (github, google code, etc.) the web apps tracker could just point there |
| 20:59 | <AryehGregor> | ++ |
| 20:59 | <Hixie> | AryehGregor: blame is near instantaneous for me, since all i use is grep |
| 21:00 | <jgraham> | Rather than doing it badly (no way to get more context) |
| 21:00 | <Hixie> | AryehGregor: how is git going to make that better? |
| 21:00 | <AryehGregor> | Hixie, it's not, given that you've already spent the effort to work around how broken svn blame is. |
| 21:00 | <Hixie> | unless git is also instantaneous, i'd have to work around git too |
| 21:01 | <AryehGregor> | It doesn't have to be instantaneous, it just has to be fast enough that it's not worth working around. |
| 21:01 | <AryehGregor> | I've never felt git blame was slow enough to bother working around, on any project I've worked on. |
| 21:01 | AryehGregor | has checked out up to r540 or so |
| 21:05 | <Hixie> | i've never felt subversion blame was too slow either until i tried using it on a 5mb document with 6000+ revisions :-) |
| 21:05 | <jgraham> | AryehGregor: < 8 minutes |
| 21:06 | <AryehGregor> | Any reasonably large software project is *way* bigger than that. MediaWiki's full repo is a gigabyte or two, with the 93010th revision committed about ten minutes ago. |
| 21:06 | <AryehGregor> | No individual text files nearly that big, of course. |
| 21:06 | <jgraham> | AryehGregor: In most reasonable projects one file doesn't change slightly in every revision |
| 21:06 | <AryehGregor> | Yes, that's certainly true. |
| 21:07 | <AryehGregor> | This is a bit of a worst-case for blame. |
| 21:07 | <jgraham> | Anyway, the spec being in git would be way more convenient |
| 21:07 | <jgraham> | Not just for blame, but particularly for diff |
| 21:08 | <AryehGregor> | Yeah. |
| 21:19 | <jgraham> | AryehGregor: Updated the html5lib tests on w3c-test.org |
| 21:20 | <AryehGregor> | jgraham, where should I submit new ones, if I were so inclined? |
| 21:20 | <jgraham> | Oh but I forgot to include the tokenizer tests |
| 21:20 | <jgraham> | AryehGregor: To the html5lib repository |
| 21:21 | <AryehGregor> | k |
| 21:21 | <jgraham> | Although you are quite welcome to mention it on public-html-testsuite if you feel so inclined |
| 21:21 | <jgraham> | The idea is that the html5lib repository has the canonical version of the test .dat files |
| 21:22 | <jgraham> | I'm not sure Kris has entirely realised / agreed with this yet mind you |
| 22:35 | <Yuhong> | FYI on base elements and security: http://i8jesus.com/?p=10 |