| 00:29 | <smaug____> | abarth: I wonder if I'm just testing Chrome+SearchBox somehow wrongly |
| 00:29 | <abarth> | smaug____: possibly, how are you testing it? |
| 00:30 | <smaug____> | abarth: well, I have google as the default engine |
| 00:30 | <abarth> | chrome://settings/browser |
| 00:30 | <abarth> | Enable Instant for faster searching and browsing |
| 00:30 | <smaug____> | and I just type 'potato' |
| 00:30 | <abarth> | should be checked |
| 00:30 | <smaug____> | what should happen? |
| 00:30 | <smaug____> | yeah, I have that instant thing enabled |
| 00:30 | <abarth> | so, don't press enter |
| 00:30 | <abarth> | you should see the SERP for potato |
| 00:30 | <smaug____> | should I have google loaded |
| 00:30 | <abarth> | nope |
| 00:30 | <abarth> | any old tab will do |
| 00:31 | <smaug____> | ok |
| 00:31 | <smaug____> | so, I load first www.helsinki.fi |
| 00:31 | <smaug____> | then type 'potato', and not enter |
| 00:31 | <smaug____> | the old page just get dimmed |
| 00:32 | <abarth> | you don't see a results page? |
| 00:32 | <smaug____> | and the dropdown under search box gives potato soup, salad, etc |
| 00:32 | <smaug____> | that is all |
| 00:32 | <smaug____> | no search page |
| 00:32 | <abarth> | ok, you must not have the feature enabled properly |
| 00:32 | <smaug____> | is it possible that google is not serving the same pages to Europe? |
| 00:33 | smaug____ | has restarted Chrome with and without the pref |
| 00:33 | <abarth> | that's possible. it's hard for me to test that |
| 00:34 | <abarth> | if you go to www.google.com |
| 00:34 | <abarth> | and type potato (without pressing enter) |
| 00:34 | <abarth> | do you see results? |
| 00:34 | <smaug____> | yeah, it does give me results |
| 00:34 | <abarth> | what happens if you type in the omnibox now? |
| 00:35 | <abarth> | (e.g., "dog" without pressing enter) |
| 00:35 | <smaug____> | google.com gets dimmed, and the dropdown under omnibox shows some results |
| 00:35 | <smaug____> | er |
| 00:35 | <smaug____> | not results |
| 00:35 | <smaug____> | but search suggests |
| 00:36 | <abarth> | what do you mean by dimmed? |
| 00:37 | <smaug____> | abarth: there is some kind of background-color: white; opacity: 0.5; layer above the page |
| 00:37 | <abarth> | does that stay indefinitely? |
| 00:38 | <smaug____> | as long as I'm using omnibox without pressing enter |
| 00:38 | <abarth> | strange |
| 00:38 | <abarth> | that's the UI for waiting for results from the server |
| 00:38 | <abarth> | sounds like you're seeing some bugs |
| 00:39 | <smaug____> | I did get one crash earlier when setting instant search enabled first time |
| 00:39 | <smaug____> | or soon after that |
| 00:40 | <smaug____> | abarth: anyway, so the idea is that when user types something to omnibox, search page is loaded and then browser communicates with that page? |
| 00:41 | <abarth> | yes |
| 00:41 | <smaug____> | where is that search page loaded? |
| 00:41 | <abarth> | in the main content area |
| 00:41 | <abarth> | just as it would be if you typed enter |
| 00:41 | <smaug____> | does the old page in the current tab get unloaded? |
| 00:41 | <abarth> | nope |
| 00:41 | <abarth> | it's just hidden |
| 00:41 | <abarth> | as if in a background tab |
| 00:41 | <abarth> | it gets unloaded if you actually navigate to the search page |
| 00:42 | <abarth> | by typing enter |
| 00:42 | <smaug____> | the API assumes a lot of things, which aren't specified :( |
| 00:42 | <abarth> | yes, the spec needs a bunch of work |
| 00:42 | <abarth> | i asked tony to do some of that work |
| 00:42 | <abarth> | and he said he was hoping other folks would be interested in it |
| 00:45 | <smaug____> | something in the API doesn't feel right... it has to do with exposing more information about browser chrome to web, and that way limit what the UI can be... |
| 00:46 | <smaug____> | need to think about this |
| 00:46 | <abarth> | i think the core use case if getting notified of typing quickly |
| 00:46 | <abarth> | so the results page can update |
| 00:46 | <abarth> | s/if/of/ |
| 00:47 | <abarth> | also, having the results page supply suggested completions via javascript is also important for performance |
| 00:47 | <smaug____> | sure |
| 00:48 | <abarth> | the occlusion stuff feels the most non-general to me |
| 00:50 | <smaug____> | abarth: why does the browser show any suggestions in this case? Couldn't all that be moved to the web page |
| 00:51 | <smaug____> | then there wouldn't be popupbox under the omnibox in this case |
| 00:51 | <abarth> | there area a bunch of different suggestions shown the dropdown |
| 00:51 | <abarth> | not all of them are searches |
| 00:51 | <smaug____> | ah, right |
| 00:55 | <smaug____> | I wonder how Google search handles the case when location bar isn't on top |
| 00:55 | <abarth> | there's probably a way to experiment with that using the web inspector |
| 00:56 | <abarth> | maybe it would make sense to separate the two parts of the proposal? |
| 00:56 | <abarth> | (the typing / suggestion data flow and the occlusion part) |
| 00:58 | <smaug____> | yeah |
| 00:58 | <smaug____> | and maybe not emphasize the "search" part so much, since also UI may overlap the page |
| 00:59 | <smaug____> | and web page may want to get data from browser UI also in some other cases. |
| 01:00 | <smaug____> | s/also UI/also other UI/ |
| 01:02 | <abarth> | AutocompleteInput ? |
| 01:03 | <abarth> | (trying to think of non-search names) |
| 04:28 | <Xdega> | are there any admins of the whatwg blog online? |
| 04:31 | <Hixie> | Xdega: here - just looking at your post in fact |
| 04:31 | <Xdega> | cool |
| 04:32 | <Hixie> | Xdega: looks good, just change the <br/><br/> stuff to <p>s so people don't poke fun at us for using <br> when the spec says not to :-) |
| 04:32 | <Hixie> | oh and remove the at the end |
| 04:33 | <Xdega> | i think WP did that on it's own. Cause I used the editor |
| 04:33 | <Hixie> | ah ok |
| 04:33 | <Hixie> | is there some way to change the markup that you can see? |
| 04:33 | <Hixie> | i can't see how to switch to it, it seems to be the default for me |
| 04:34 | <Hixie> | let me know if you can't, and i can do it |
| 04:36 | <Xdega> | yah, there is a html tab |
| 04:37 | <Xdega> | i was fixing it, but noticed someone else was editing it simultaneously. heh |
| 04:38 | <Hixie> | if it said "ian hickson" or "admin" was editing it that's cos i was logged in and looking at it |
| 04:38 | <Hixie> | i noticed it said anne had touched it recently but i thought he was off on some faraway island or something |
| 04:38 | <Xdega> | k |
| 04:40 | <gsnedders> | Hixie: I'm not sure South America (somewhere) counts as a faraway island. :) |
| 04:41 | <Xdega> | heh, well post markup fixd :D |
| 04:43 | <Xdega> | worst part is the wysiwyg editor in wp auto added xhtml style br tags, lol |
| 04:43 | <Hixie> | gsnedders: it's an island far from you, isn't it? :-P |
| 04:44 | <Hixie> | Xdega: |
| 04:44 | <Hixie> | cool |
| 04:44 | Hixie | tries to remember how to log into the blog again |
| 04:45 | <Xdega> | http://blog.whatwg.org/wp-login.php |
| 04:45 | <Hixie> | yeah i found it |
| 04:48 | <Hixie> | man i really should let the experts do this |
| 04:48 | Hixie | fights with wordpress :-P |
| 04:48 | <Hixie> | ok! |
| 04:48 | <Hixie> | you should now have the right to publish your post |
| 04:49 | <Hixie> | hopefully i didn't break anything in the process |
| 04:49 | <Xdega> | cool |
| 04:49 | Hixie | logs out quickly to limit the damage he can cause :-P |
| 04:52 | <Xdega> | heh, alright. Blog entry published. good deal |
| 04:52 | <Xdega> | thx |
| 04:53 | <Hixie> | thank _you_! |
| 04:54 | <Xdega> | well 12am where I am. + Work bright and early = Bed Time. |
| 04:54 | <Xdega> | nn guys :D |
| 04:55 | <Hixie> | nn! |
| 05:09 | <othermaciej> | hi everyone |
| 05:12 | othermaciej | just returned from 2 weeks in no-internet-land |
| 05:15 | <heycam> | othermaciej, come on, australia has internet |
| 05:15 | <heycam> | in places |
| 05:15 | <heycam> | :) |
| 05:15 | <othermaciej> | heycam: unfortunately, those places do not include Uluru or the Coral Sea |
| 05:16 | <heycam> | ah, nice! never been there myself. |
| 05:16 | <othermaciej> | (both very nice places, despite the lack of internet and high concentration of deadly flora and fauna) |
| 05:26 | <Hixie> | nessy: yt? |
| 05:26 | <Hixie> | othermaciej: yay, you returned! |
| 05:26 | <Hixie> | othermaciej: did you see the sky at night at Uluru? |
| 05:26 | <othermaciej> | hey there Hixie! |
| 05:26 | <othermaciej> | Hixie: yes |
| 05:26 | <othermaciej> | I even brought an iPad star chart app so I could identify the stars |
| 05:27 | <Hixie> | othermaciej: that's the most beautiful skyscape i've ever seen |
| 05:27 | <othermaciej> | spotting the milky way, the southern cross and orion was easy |
| 05:27 | <Hixie> | othermaciej: (only place i've ever been with no other lights) |
| 05:27 | <othermaciej> | but I am not sure I would have identified the Magellanic Clouds otherwise |
| 05:27 | <Hixie> | cool |
| 05:27 | <othermaciej> | or Saturn |
| 05:28 | <othermaciej> | GPS / accelerometer based star chart is so win |
| 05:28 | <Hixie> | yeah |
| 05:28 | <Hixie> | google sky, or something else? |
| 05:28 | <Hixie> | google sky is pretty sweet |
| 05:28 | <Hixie> | haven't played with it much though |
| 05:28 | <othermaciej> | it was one called RedShift |
| 05:28 | <Hixie> | ah, cool |
| 05:28 | <Hixie> | haven't seen that one |
| 05:28 | <othermaciej> | (and my girlfriend had Sky Walk) |
| 05:28 | <othermaciej> | I hadn't heard of Google Sky |
| 05:28 | <Hixie> | it's basically the opposite of google earth |
| 05:29 | <Hixie> | on the desktop it's just a subfeature of earth |
| 05:29 | <Hixie> | on mobile it's a separate app |
| 05:30 | <othermaciej> | doesn't seem to exist for iOS, unless it has a non-obvious name |
| 05:30 | <Hixie> | ah, yeah, might not be on iOS |
| 05:30 | <Hixie> | it's probably a 20% project |
| 05:31 | <Hixie> | so it probably just runs on the platform that whoever wrote it uses :-) |
| 05:32 | <othermaciej> | anyway, you definitely can't find a place with that little light pollution anywhere in california |
| 05:32 | <Hixie> | yeah no kidding |
| 05:33 | <Hixie> | other than the middle of the ocean, you'd probably be hardpressed anywhere |
| 05:33 | <Hixie> | i doubt anywhere in europe is anywhere like that for instance |
| 05:35 | <kig> | lapland maybe |
| 05:40 | <othermaciej> | I've previously noticed that just about any place in Australia that is far from major cities has a good night sky view |
| 05:40 | <othermaciej> | I would be there are places in Alaska or Canada that are far enough |
| 09:17 | <jgraham> | AryehGregor: Did you ever make a pacth for prettyprinting in testharness.js? |
| 09:17 | <jgraham> | *patch |
| 10:59 | <Hixie> | right. sent a proposal for -152. |
| 10:59 | <Hixie> | nn. |
| 12:18 | <jacobolus> | someone maybe mention to Shelley that Columbia ≠ Colombia :) |
| 12:21 | <jacobolus> | otherwise, the weekly looks good |
| 12:35 | <hsivonen> | jgraham: this test doesn't comply with the documented test format: http://code.google.com/p/html5lib/source/diff?spec=svne4a9be41411d8592c858a4618a0cc68e2a6b2378&r=99e8af7f0c486da0f7ca7e570177d8f7b9f68ed4&format=side&path=/testdata/tree-construction/tests26.dat |
| 12:36 | <hsivonen> | fixed now |
| 13:02 | <jgraham> | hsivonen: Thanks |
| 13:03 | <jgraham> | The <time> element is supposed to render its datetime attribute, right? |
| 13:03 | <jgraham> | Or rather the parsed values of it |
| 13:04 | <jgraham> | Per http://www.whatwg.org/specs/web-apps/current-work/#the-time-element-0 |
| 13:06 | <jgraham> | However http://www.whatwg.org/specs/web-apps/current-work/#the-time-element has an example |
| 13:06 | <jgraham> | <time class="dtend" datetime="2007-10-20">19</time> |
| 13:06 | <jgraham> | (The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.) |
| 13:07 | <jgraham> | Which seems problematic given that a supporting UA will render 2007-10-20 not 2007-10-19 |
| 13:08 | <hsivonen> | I wonder if it is intentional that text in a MathML text integration point doesn't reconstruct the active formatting elements |
| 13:11 | <matjas> | someone with access to the @whatwg Twitter account should really tweet about the new WHATWG Weekly |
| 13:12 | <hsivonen> | who has twitter access except annevk? |
| 13:13 | <hsivonen> | the blog post UI has an option to tweet upon publishing. I guess it didn't get checked this time. |
| 13:16 | <jgraham> | hsivonen: Thanks for bugging the MathML text integration point stuff |
| 13:17 | <hsivonen> | jgraham: Ragnarök implements it per spec, FWIW |
| 13:27 | <smaug____> | what is "WHATWG Weekly"? |
| 13:27 | <hsivonen> | smaug____: a blog post series |
| 13:30 | <anne-vac> | it seems the WordPress plugin we use for twitter broke |
| 13:30 | <jgraham> | Well that only lasted a week |
| 13:30 | <anne-vac> | as we are mostly recovering this morning from a night bus to Medellin I thought I could drop in |
| 13:32 | <anne-vac> | anyone who wants to take over maintaining the twitter account_ |
| 13:32 | <anne-vac> | ? i mean |
| 13:32 | <anne-vac> | weird keyboards around here |
| 13:32 | <anne-vac> | I retweeted the tweet from shelley for now |
| 13:33 | <Lachy> | anne-vac, the twitter plugin offered an update and I just installed it about an hour or two ago. |
| 13:34 | <Lachy> | I just assumed it was still working |
| 13:34 | <anne-vac> | k |
| 13:34 | <anne-vac> | someone should also educate people about the URL feature of WordPress |
| 13:34 | <hsivonen> | well, this is rather useless. ghex2--a hex editor--won't copy and paste data with a zero byte in it! |
| 13:35 | <Lachy> | the WP Dashboard also now displays the notice "Twitoaster Plugin is deprecated! Please read this announcement for more information" http://blog.twitoaster.com/twitoaster-shutting-down |
| 13:35 | <anne-vac> | yeah, we should find something else |
| 13:35 | <anne-vac> | there is a feed to twitter thingie somewhere, but that is not live |
| 13:36 | <anne-vac> | i rather have something live |
| 13:37 | <anne-vac> | nobody volunteering to maintain twitter? |
| 13:39 | <hsivonen> | anne-vac: I suppose I could volunteer |
| 13:42 | <anne-vac> | alright, hsivonen is the one to bug now :) |
| 13:43 | <Lachy> | hsivonen, I disabled Twitoaster |
| 13:44 | <Lachy> | you can uninstall it I guess, and install whatever |
| 13:47 | <hsivonen> | Lachy: my current plan is to tweet manually once per week until anne-vac returns it becomes his problem again |
| 13:52 | <anne-vac> | time to play cards on the balcony ;-) |
| 14:00 | <jgraham> | So, logically, I must have an account on the blog since I have posted on it and stuff. But I have no idea what the email address for it is, even |
| 14:00 | gsnedders | uses his 1337 hacker skillz to find out |
| 14:01 | <gsnedders> | jgraham: @opera.com |
| 14:04 | <AryehGregor> | jgraham, no, I saw all the twisty formatting code and gave up. The actual pretty-printing part is easy, I already made a function for that: http://dvcs.w3.org/hg/html/file/8f1a0cc1800b/tests/submission/AryehGregor/reflection/original-harness.js#l16 |
| 14:08 | <AryehGregor> | It would probably be safe enough to shoehorn in the pretty-printing at the level of assert_*, though. |
| 14:37 | <jgraham> | AryehGregor: That's what I was expecting you to do |
| 14:38 | <jgraham> | Pretty-priting all subsitutions seems dangerous because sometimes you want "" to be output as the empty string and not quote characters |
| 14:58 | <hsivonen> | jgraham: is the point of ark.dat that setting the attribute has an effect on the Noah's Ark rule? |
| 14:59 | <hsivonen> | jgraham: if so, I believe the test is wrong. |
| 14:59 | <hsivonen> | or if the test isn't wrong, the spec is. |
| 14:59 | <hsivonen> | because we wanted the tree builder never to read back from the DOM |
| 14:59 | <jgraham> | hsivonen: I thought it was supposed to test that it didn't have an effect |
| 15:00 | <jgraham> | It is not impossible that I checked in a broken version of the test by mistake |
| 15:00 | <hsivonen> | jgraham: interesting. I'm extremely sure that Gecko can't possibly read back from the DOM, and the result doesn't match the expected results |
| 15:01 | <hsivonen> | jgraham: at least it was broken in the sense that it didn't have a newline at the end of the file :-) |
| 15:10 | <hsivonen> | https://bugs.webkit.org/show_bug.cgi?id=56727 What's the status in the CSS WG? |
| 15:10 | <jgraham> | hsivonen: The ark test is clearly broken because it has a <font> as a child of the <script> |
| 15:11 | <jgraham> | hsivonen: Which is a bug I fixed at least once :( |
| 15:11 | <jgraham> | hsivonen: With that fixed I think the test is right |
| 15:11 | <jgraham> | and tests that we reconstruct using the original token rather than the DOM |
| 15:13 | <jgraham> | hsivonen: (If you have the file open right now and can push a fix, I would appreciate it) |
| 15:14 | <hsivonen> | jgraham: ok |
| 15:19 | <hsivonen> | jgraham: fixed |
| 15:21 | <jgraham> | hsivonen: Thanks |
| 16:27 | <TabAtkins> | hsivonen: Mixins haven't been proposed yet, because I haven't found time to do so yet. Glazman posted a comment on the bug to that effect about an hour ago. |
| 16:33 | <AryehGregor> | elRTE.prototype.ui.prototype.buttons.button.prototype.command = function() { |
| 16:33 | <AryehGregor> | . . . |
| 16:33 | <TabAtkins> | ... |
| 16:33 | <AryehGregor> | Does my astonishment at that line indicate my JavaScript naivete, or am I correct that that looks kind of crazy? |
| 16:33 | <TabAtkins> | The latter. |
| 16:33 | <AryehGregor> | Good. |
| 16:34 | <bga_> | TabAtkins Class.prototype = Class; |
| 16:35 | <TabAtkins> | That's just rooting a prototype tree. ^_^ |
| 16:35 | <TabAtkins> | (Object.prototype == Object) |
| 16:37 | <bga_> | TabAtkins since i "invent" this trick i forget about 'prototype' word :) |
| 16:51 | <nessy> | Hixie: nice change proposal! |
| 17:37 | <beowulf> | are localStorage events implemented in any browser? |
| 17:47 | <beowulf> | "The storage event is supported everywhere the localStorage object is supported, which includes Internet Explorer 8." # is that true? http://diveintohtml5.org/storage.html |
| 17:47 | <AryehGregor> | Very likely, if diveintohtml5.org says it. |
| 18:08 | <beowulf> | gah, need two tabs open |
| 18:09 | <TabAtkins> | Grr, I hate trying to read dense declarative formats. |
| 19:14 | <AryehGregor> | Wow, Selection.collapse() is an interop trainwreck. |
| 19:15 | <AryehGregor> | Opera seems to actually treat it like removeAllRanges(). |
| 19:16 | <AryehGregor> | IE9 seems to get most cases right if they're sane, which means it only fails about two-thirds of my tests. |
| 19:16 | <AryehGregor> | WebKit's Selection.collapse() makes me want to cry tears of blood. |
| 19:16 | <AryehGregor> | I don't know *what* it's doing. |
| 19:19 | <AryehGregor> | Maybe it's just because WebKit's Selection implementation is completely nonstandard and can only select things that are actually visible. |
| 19:20 | <AryehGregor> | I think that explains most of it |
| 19:20 | <AryehGregor> | . |
| 19:26 | <TabAtkins> | What is collapse() supposed to do in the first place? |
| 19:27 | <othermaciej> | I would assume it's supposed to collapse the selection to a caret (though at which end, I don't know) |
| 19:33 | <AryehGregor> | TabAtkins, othermaciej, it's called like selection.collapse(node, offset), and it collapses the selection to the given place. |
| 19:33 | <AryehGregor> | Range.collapse() collapses it to the start or end, depending on whether you pass true or false as its parameter (don't ask me which is which). |
| 19:33 | <AryehGregor> | I dunno who decided to name those two methods the same thing when they mean something entirely different. |
| 19:34 | <AryehGregor> | (WebKit's Range implementation is fine, it's only its Selections that are really weird) |
| 19:34 | <othermaciej> | our Selection tries to limit endpoints to selections that could be created by user interaction |
| 19:35 | <AryehGregor> | Which is reasonable in principle, perhaps, but not what anyone else does, or what the spec says. |
| 19:35 | <AryehGregor> | Maybe not reasonable in principle, either, because it makes the behavior of Selection stuff depend on, e.g., CSS. |
| 20:53 | <jgraham> | heycam: yt? If I have a readonly property and I apply the delete operator, what happens? I feel there is some magic spec text I am overlooking |
| 20:55 | <heycam> | hi jgraham |
| 20:55 | <heycam> | the behaviour falls out just due to the attributes of the property |
| 20:56 | heycam | will find spec text link |
| 20:57 | <jgraham> | heycam: That's what I thought, but I couldn't see why it would return true if that were the case |
| 20:58 | <jgraham> | So I guess I missed something |
| 20:58 | <heycam> | hmm, how does delete work when you use it on an object and the property comes from the prototype? |
| 20:59 | <heycam> | if you do `delete Node.prototype.nodeType`, that should actually remove the property, since properties for attributes are configurable now, per spec |
| 21:00 | <heycam> | (they were originally ReadOnly, when the spec targetted ES3, and that carried over to them being non-configurable, until a recent change) |
| 21:00 | <jgraham> | Ah |
| 21:00 | <heycam> | ok so `delete myNode.nodeType` should return true and do nothing |
| 21:00 | <heycam> | because there's no own property "nodeType" on the instance |
| 21:01 | <jgraham> | What about delete on the prototype object? |
| 21:01 | <heycam> | that will remove it and return true |
| 21:01 | <jgraham> | OK |
| 21:02 | <jgraham> | It seems that it was not my reading comprehension skills that were at fault but my assumptions |
| 21:03 | <jgraham> | To be clear, all properties except constants are now defined on the prototypes rather than on instances? |
| 21:03 | <jgraham> | so e.g. document.hasOwnProperty("createElement") is false |
| 21:04 | <heycam> | jgraham, that's right |
| 21:04 | <heycam> | hmm is that true about constants? |
| 21:05 | <jgraham> | I might be misremembering |
| 21:05 | <heycam> | no, constants go both on the interface object itself and the prototype |
| 21:06 | <jgraham> | Yeah, sorry I confused the interface object and the instance object |
| 21:06 | <jgraham> | Right, it all makes sense now :) |
| 21:06 | <jgraham> | For small values of all |
| 21:07 | <heycam> | :) |
| 21:07 | <jgraham> | heycam: thanks :) |
| 21:07 | <heycam> | np |
| 21:27 | <nessy> | is wiki.whatwg down? |
| 21:27 | <Hixie> | does seem that way |
| 21:27 | <Hixie> | weird |
| 21:28 | <tw2113> | It's not just you! - http://wiki.whatwg looks down from here. |
| 21:28 | <tw2113> | according to the bot in #html5 |
| 21:28 | <Hixie> | oh, there it is |
| 21:28 | <Hixie> | ok it's up |
| 21:28 | <Hixie> | dunno what that was about |
| 21:28 | <nessy> | thanks :) |
| 21:29 | <tw2113> | it hiccuped |
| 21:29 | <nessy> | I take it personal |
| 21:29 | <Hixie> | btw you'll notice that wiki.whatwg.org is now on IPv6 :-) |
| 21:29 | <Hixie> | (as are all my sites now) |
| 21:30 | <nessy> | ah, the big ipv6 day |
| 21:30 | <Hixie> | happened a few days ago actually |
| 21:30 | <nessy> | are you at MTV today? |
| 21:30 | <Hixie> | yeah |
| 21:30 | <nessy> | am here, too |
| 21:31 | <tw2113> | here's a good question |
| 21:32 | <tw2113> | should we be viewing the IPv4 vs IPv6 as a complete move or an expansion? |
| 21:32 | <tw2113> | sort of like adding a million rooms to a house instead of moving into a million room larger house |
| 21:32 | <tw2113> | although i know IPv6 will offer more addresses than we'll ever need |
| 21:34 | <Hixie> | IPv6 doesn't add _that_ many addresses |
| 21:34 | <tw2113> | gotcha, just curious |
| 21:38 | <AryehGregor> | Hixie, it adds approximately 6.7 x 10^23 addresses per square meter of the Earth's surface. |
| 21:39 | <AryehGregor> | Which is slightly more than Avogadro's number, as Andrew S. Tanenbaum points out in his networking textbook. |
| 21:39 | <Hixie> | yeah but the entire top half of the address space is for in-subnet host identifications |
| 21:39 | <Hixie> | so it's only really 2^64 subnets |
| 21:39 | <Hixie> | not 2^128 hosts |
| 21:39 | <tw2113> | and we have to account for 10 different addresses per person |
| 21:40 | <Hixie> | and that's not even enough for one subnet per known star |
| 21:40 | <tw2113> | because we're all hyperconnected these days |
| 21:40 | <Hixie> | let alone per planet or per user on all those planets |
| 21:40 | <AryehGregor> | Nobody says we can't change how we assign the addresses later. |
| 21:40 | <Hixie> | yeah cos that worked so well with ipv4 |
| 21:40 | <AryehGregor> | IPv4 originally had addresses only assigned in Class A, B, or C blocks, right? |
| 21:40 | <Hixie> | we only used about 15% of ipv4 by the time it was "completely exhausted" |
| 21:41 | <AryehGregor> | 15% of 2^128 is an awful lot more than 2^64. |
| 21:41 | <othermaciej> | if we ever run IP at interstellar scales, it will need a version bump anyway |
| 21:41 | <AryehGregor> | Granted it will always be underallocated due to routing concerns, but not by a factor of 2^64. |
| 21:41 | <othermaciej> | to increase the maximum timeout to hundreds of years |
| 21:42 | <AryehGregor> | Aren't timeouts a TCP feature? |
| 21:42 | <Hixie> | ipv6 is obviously a whole heck of a lot bigger than ipv4, i'm just saying that we shouldn't get cocky and think it's more addresses than we'll ever need |
| 21:42 | <othermaciej> | I believe IP has a maximum TTL before your packets get dropped |
| 21:43 | <AryehGregor> | Yeah, but isn't the TTL in hops, not seconds? |
| 21:43 | <Hixie> | vint has already worked on a variant of IP for interplanetary use |
| 21:43 | <Hixie> | i believe it's what is used to communicate with the devices in orbit around mars |
| 21:44 | <othermaciej> | yeah, but, there we're talking order of minutes, not years / hundreds of years for transit time |
| 21:44 | <Hixie> | i don't know the specifics |
| 21:47 | <AryehGregor> | Realistically, the model of a single network where any address is transparently addressable breaks down when you get to a scale of anything close to light-years. |
| 21:47 | <AryehGregor> | It makes no sense for transport or application layers to be agnostic about whether they're communicating with someone 100 ms away or 100 years away. |
| 21:48 | <AryehGregor> | If you were communicating with faraway planets, you'd very likely want to use different protocols all down the stack. |
| 21:48 | <AryehGregor> | I mean, they could share some things, but I doubt IP-addressability is going to be an important requirement. |
| 21:51 | <Hixie> | one can imagine a situation in which one would want to have one virtual host per star, or some such, in which case the number of stars is relevant but their relative distance is not. but i'm just making stuff up here. :-) |
| 21:52 | <Hixie> | i just think it's silly to say things along the lines of "more [...] than we'll ever need" since historically there's always come a time where someone has come up with something that needs more |
| 21:53 | <Hixie> | maybe we'll be numbering atoms by IP address, in which case 6.7 x 10^23 addresses limits us to one mole, which isn't much at all, e.g. |
| 21:53 | <Hixie> | it's sufficient addresses for the forseeable future though |
| 21:53 | <AryehGregor> | But that will only hold true until we make the numbers large enough to exceed any relevant physical limits. |
| 21:54 | <Hixie> | not if we transcend the relevant physical limits :-) |
| 21:54 | <Hixie> | and one can easily have a host that responds to 2^128 addresses without having to have 2^128 rows in a configuration file or whatnot |
| 21:55 | <AryehGregor> | For instance, ZFS uses 128-bit block pointers on the theory that the information entropy of storing 2^128 bits would be enough to boil the oceans. |
| 21:55 | <AryehGregor> | I'll grant that that's not a totally bulletproof argument. |
| 21:55 | <AryehGregor> | But it's fair to say that "2^128 blocks is all a filesystem will ever need" is much more likely to be true than "640 KB is all anyone will ever need". |
| 21:55 | <AryehGregor> | It's a qualitatively different sort of statement. |
| 21:56 | <Hixie> | both are unjustifiably unqualified, imho |
| 21:56 | <Hixie> | it's easy to add "for the forseeable future" :-) |
| 21:59 | <uf0> | guys, what you feel about multiple h2 tags |
| 22:00 | <uf0> | example: <h1>search result for: johnny</h1>... <h2>result title 1</h2> <h2>result title 2</h2> |
| 22:00 | <TabAtkins> | What about it? |
| 22:00 | <uf0> | or should those be result titles be <h3> |
| 22:01 | <Hixie> | doesn't matter |
| 22:01 | <uf0> | question is.. should it multiple h2 or h3 |
| 22:01 | <TabAtkins> | Why do you think there's a difference? |
| 22:01 | <uf0> | doesn't it according to Mr. Google |
| 22:01 | <Hixie> | mr google cares about the quality of your content |
| 22:01 | <Hixie> | not about whether you use h2 or h3 |
| 22:02 | <uf0> | i know, but they clearly put emphasis on a H1 tag |
| 22:02 | <uf0> | so that's why i wonder about h2s 3s |
| 22:02 | <uf0> | for arguments sake, which one would you guys use? |
| 22:03 | <Hixie> | personally i'd use <section> and <h1> |
| 22:03 | <Evet> | anyone tried amplesdk + xul? |
| 22:03 | <Hixie> | uf0: as in <body> <h1>page title</h1> <section> <h1>subtitle</h1> ...content... </section> <section> <h1>subtitle</h1> ...content... </section> </body> |
| 22:05 | <uf0> | Hixie: H1 for page title and subtitle? hmm |
| 22:08 | <uf0> | alright |
| 22:19 | <Hixie> | uf0: <section> resets the scope for <h1> |
| 22:19 | <Hixie> | uf0: see the spec :-) developers.whatwg.org |
| 22:24 | <uf0> | gotcha thanks hixie |
| 22:30 | <pkzip> | I have a spec query... |
| 22:30 | <pkzip> | ... anyone want to take it? |
| 22:31 | <AryehGregor> | pkzip, ask and you'll find out. |
| 22:31 | <TabAtkins> | Ask questions, not questions about your questions, please. ^_^ |
| 22:32 | <pkzip> | Ok, well here we go. A table, height 100%,, in a body, html of height 100%. Two rows. First fixed height (say 100px), the other auto height. |
| 22:33 | <pkzip> | The spec doesn't define how a child of the cell in the second, auto-height row calculates its height. |
| 22:33 | <TabAtkins> | Correct. Table rendering is essentially undefined. |
| 22:33 | <TabAtkins> | (Unfortunately.) |
| 22:33 | <pkzip> | Chrome does the obvious thing. |
| 22:33 | <pkzip> | But IE and FF don't. And I think it would be very useful if FF at least copied Chrome, so that say a div of height 100% in the second td |
| 22:34 | <pkzip> | fills it up, rather than trying to be the same height as the entire table |
| 22:34 | <pkzip> | which IMO makes no sense. |
| 22:34 | <AryehGregor> | I suspect no one's going to be willing to change their algorithms much until someone writes a spec. |
| 22:34 | <TabAtkins> | Put a bug on them, then? Like I said, there is *not* any spec text actually mandating a behavior here. At the moment it's purely a quality-of-implementation issue. |
| 22:34 | <AryehGregor> | Too much risk of breaking stuff. |
| 22:34 | <AryehGregor> | But you could try to file a bug against Firefox. |
| 22:34 | <pkzip> | Okay. So that's the thing to do, file a bug? |
| 22:35 | <TabAtkins> | For now, yeah, that's the best you can do. No promises about what it'll accomplish, though. |
| 22:35 | <TabAtkins> | I'm curious as to why you're using a screen-filling table as a direct child of <body>, though. |
| 22:35 | <TabAtkins> | That sounds like a layout table. |
| 22:35 | <pkzip> | Yeah I get that. So here's a meta-question- I thought one of the points of html5 was to standardise stuff like this. |
| 22:35 | <AryehGregor> | This is CSS, not HTML. |
| 22:36 | <TabAtkins> | This is a CSS issue, not an HTML issue. |
| 22:36 | <pkzip> | Ohhhh. :) |
| 22:36 | <AryehGregor> | But yes, you're right more generally. |
| 22:36 | <AryehGregor> | We do want to standardize things like this. |
| 22:36 | <AryehGregor> | But there's loads and loads of stuff to standardize, and no one's gotten around to this specific one yet. |
| 22:36 | <jgraham> | You could file a bug against TabAtkins to make him work on this |
| 22:36 | <TabAtkins> | Indeed. The only problem is that no one has so far wanted to spend the effort to write a Table Module. |
| 22:36 | <jgraham> | Or against his manager to assign him to work on it |
| 22:36 | <AryehGregor> | Hopefully someone will standardize it in the not-too-distant future. |
| 22:37 | jgraham | doesn't know if TabAtkins or anyone above him in the heirachy has a public bugtracker though :) |
| 22:37 | <TabAtkins> | I do not, thank the gods. |
| 22:37 | <TabAtkins> | Though that would be pretty funny. |
| 22:37 | <TabAtkins> | And... maybe useful? |
| 22:38 | <pkzip> | This is table-for-layout, btw. Because there's still stuff that only tables are good for. |
| 22:38 | <TabAtkins> | pkzip: I doubt that you actually need a table for what you're doing. It's possible, but I've been able to get *very* far without them. |
| 22:39 | <TabAtkins> | (Leaning on display:table has solved some of the problems I've run into, of course.) |
| 22:39 | Hixie | pokes nessy to read her e-mail :-P |
| 22:40 | <pkzip> | Okay, well display:table too. But display:table ends up with exactly the issue I first described, of course! |
| 22:40 | <TabAtkins> | Yes. |
| 22:42 | <pkzip> | Okay bug it is then. Thanks. |