| 00:10 | <Johnny__> | Does it make sense to nest two aside tags into one aside tag? I need to place two things one beside the other and float them so the one on the right won't go on the next row. |
| 04:29 | <MikeSmith> | nessy: about the report of problems with links in the http://lists.w3.org/Archives/Public/public-html/feed.rss feed |
| 04:30 | <MikeSmith> | the feed readers I've tried do handle those links as expected |
| 04:30 | <MikeSmith> | e.g., if I click on the first link, it takes me to http://lists.w3.org/Archives/Public/public-html/2010Feb/0221.html |
| 04:47 | <MikeSmith> | hmm, I guess those are supposed to be absolute URIs |
| 06:05 | <TheOutlawTorn> | Morning. |
| 06:06 | <MikeSmith> | TheOutlawTorn: hey |
| 06:07 | <MikeSmith> | nessy: I filed a systems bug for the RSS feed link problem |
| 06:07 | <TheOutlawTorn> | Is this considered correct use of the following tags: <div id="someClass"><aside id="one">some stuff</aside><aside id="two">some stuff again</aside></div> |
| 06:07 | <nessy> | MikeSmith: excellent - wondered if there was some setup issue |
| 06:07 | <nessy> | thanks! |
| 06:07 | <TheOutlawTorn> | Basically I need to have a big block inside which I will position (using floats) something on the left and something besides it on the right. |
| 06:08 | <TheOutlawTorn> | I'm not sure I'm using the new tag correctly though. |
| 06:10 | <MikeSmith> | nessy: it seems that many (or maybe even most) feed readers resolve those into absolute URIs, but regardless, the feed validator says relative URIs in rss <link> elements aren't valid, so we should fix it |
| 06:10 | <MikeSmith> | TheOutlawTorn: is your content all <aside>s? |
| 06:11 | <TheOutlawTorn> | Everything is inside a <section> tag. The content is above the aside tags |
| 06:12 | <MikeSmith> | so if the asides are stuff that you are having rendered as sidebars around the main content, then it would seem you are using it as intended |
| 06:12 | <TheOutlawTorn> | Well I'm placing a form in one and some text in the other |
| 06:13 | <MikeSmith> | all sounds fine |
| 06:13 | <TheOutlawTorn> | Hm, ok. |
| 06:13 | <MikeSmith> | that would all validate, as far as I can see |
| 06:13 | <MikeSmith> | but you can always check at http://validator.nu/ to make sure |
| 06:13 | <TheOutlawTorn> | It validates, sure. |
| 06:21 | <MikeSmith> | TheOutlawTorn: if it validates, then the question about usage is mostly a subjective judgement call |
| 06:21 | <MikeSmith> | you could probably find somebody who might think the way you are using it is wrong |
| 06:21 | <TheOutlawTorn> | I see.. thanks |
| 08:14 | <MikeSmith> | hsivonen: link about the Oracle-Gnome accessibility news? |
| 08:14 | <MikeSmith> | nm |
| 08:14 | <MikeSmith> | found it |
| 08:46 | <annevk> | do about: URIs need some kind of wiki registry as well? |
| 08:52 | <MikeSmith> | how many are there currently? |
| 08:52 | <MikeSmith> | annevk: ↑ |
| 08:52 | <MikeSmith> | and are we planning to add many more? |
| 08:57 | <Philip`> | Are there any where interoperability is needed, except about:blank? |
| 08:58 | <annevk> | MikeSmith, the sandbox stuff ended up adding one |
| 08:58 | <annevk> | MikeSmith, if people start using them for icons that would be at least one more |
| 08:58 | <MikeSmith> | hmm |
| 08:58 | <MikeSmith> | 困った |
| 08:59 | <MikeSmith> | it seems like a registry might have an unintended side-effect of encouraging further proliferation of about: stuff |
| 09:00 | <zcorpan> | google translate couldn't detect the language for "困った" but could for "困った困った" |
| 09:00 | <MikeSmith> | weird |
| 09:01 | <MikeSmith> | I wonder how it translates it |
| 09:01 | <zcorpan> | Trouble trouble |
| 09:02 | <MikeSmith> | try 困ったな |
| 09:02 | <zcorpan> | Damn |
| 09:02 | <MikeSmith> | that's more like it |
| 09:06 | <annevk> | i guess it's not really needed |
| 09:07 | <annevk> | though some overview would be nice |
| 09:07 | <annevk> | i like overviews :) |
| 09:12 | <MikeSmith> | it would be nice for any new registries to use some innovative technology of the last 30 years, such as, say, an actual database backend |
| 09:14 | <hsivonen> | does anyone have a reference to an authoritative Google statement on the breadth of the H.264 decoding license a user get for Chrome? |
| 09:14 | <hsivonen> | http://www.google.com/chrome/intl/en/eula_text.html says nothing on the topic |
| 09:15 | <hsivonen> | (for background, Flash Player appears to be licensed only for non-commercial decoding) |
| 09:15 | <hsivonen> | freedom zero FTW |
| 09:18 | <MikeSmith> | hsivonen: I don't remember public statements except what was posted to the whatwg list |
| 09:19 | <hsivonen> | MikeSmith: thanks |
| 09:19 | <annevk> | hsivonen, is it non-commercial if you make money of advertizements? |
| 09:21 | <jgraham> | annevk: Doesn't that make commercial TV non-commercial? |
| 09:21 | <jgraham> | (I know TV is different) |
| 09:22 | <hsivonen> | annevk: IANAL, but I doubt the user of Flash Player is the one making money from advertisements when decoding is practiced |
| 09:22 | <annevk> | I thought commercial TV was TV not sponsored by the government |
| 09:22 | <hsivonen> | Is BBC World commercial or non-commercial under that definition? |
| 09:22 | <jgraham> | (but the point is it is a pretty weird defenition of "non-commercial" that includes the main way that video has amde money since its inception) |
| 09:23 | <annevk> | The public channels do advertising as well |
| 09:23 | <jgraham> | s/video/TV/ maybe. Or whatever the term is for "recorder moving images" |
| 09:23 | <jgraham> | *recorded |
| 09:23 | <hsivonen> | having different licensing terms for commercial and non-commercial use is a trap. |
| 09:24 | <hsivonen> | setting those traps is uncool |
| 09:24 | <hsivonen> | (I'm looking at you, Creative Commons.) |
| 09:24 | jgraham | is quite happy to put photos under a non-nomercial CC license |
| 09:24 | <jgraham> | argh |
| 09:24 | <jgraham> | commercial |
| 09:24 | <jgraham> | That wasn't even close |
| 09:25 | <jgraham> | But I would be somewhat less happy to put them under a simply BY license |
| 09:26 | <hsivonen> | jgraham: so someone else creates a larger work that includes your photos somewhere. Then later they find they want to make some money from their work. |
| 09:26 | <hsivonen> | jgraham: so they can't presumptively |
| 09:27 | <hsivonen> | which sucks |
| 09:27 | <hsivonen> | or they need to make more money than it costs to negotiate commercial licenses, which sucks |
| 09:27 | <Philip`> | It seems the problem is when people think CC-NC means "free but with some extra restrictions" instead of "proprietary but with some exceptions" |
| 09:27 | <hsivonen> | and you can extort them for money up to the cost of removing and replacing your photos |
| 09:27 | <jgraham> | hsivonen: In my spoecific case it would almost always be a case of "ask, get permission" |
| 09:28 | <hsivonen> | so effectively CC-NC is an attractive nuisance |
| 09:29 | <hsivonen> | creators of larger works would be smarter to search Flickr for someone else's less good photos instead than take the risk of not being able to make money from their additive creativity |
| 09:29 | <jgraham> | hsivonen: You would prefer things were "all rights reserved" than BY-NC |
| 09:29 | <hsivonen> | jgraham: yes |
| 09:29 | <jgraham> | Curious. |
| 09:30 | <jgraham> | There are many instances where you are clearly never intending to make money from a project e.g. one-off presentations at science conferences |
| 09:31 | <jgraham> | However it is generally not worth the effort of asking for permission to use some nice pictures in those cases |
| 09:31 | <Philip`> | Do people giving presentations at science conferences care about licenses, and not just crawl through Google Images looking for suitably amusing clipart they can grab without worrying about where it came from? |
| 09:31 | <jgraham> | I did. I'm not sure about anyone else |
| 09:32 | <Hixie> | it's not clear those cases would even be violations of copyright law, depending on how many people watch your talk |
| 09:32 | <jgraham> | But I guess there is a higher-than-average chance of people doing that sort of thing abiding by the rules |
| 09:32 | <hsivonen> | jgraham: NC is basically this problem: http://www.techdirt.com/articles/20090117/0537253446.shtml |
| 09:33 | <hsivonen> | the saddest part of it is how Lessig goes on the talking circuit talking about the problems documentary makers face in this area |
| 09:34 | <hsivonen> | and then his own organization is effectively promoting the same problem |
| 09:34 | <hsivonen> | that if you later find your larger work could be used in a way you didn't plan for, you are in a permission culture hell |
| 09:44 | <annevk> | Hixie, I reckon he might have told you in private already, but just in case: http://bitworking.org/news/2010/02/joel-in-a-box |
| 09:44 | <annevk> | Hixie, also, if you're out there, did you see my notes on XMLHttpRequest from yesterday? |
| 09:44 | <annevk> | Hixie, I was wondering if you agree it could use "fetch" if synchronous requests were told to "pause" |
| 09:44 | <othermaciej> | howdy folks |
| 09:45 | <annevk> | heya othermaciej |
| 09:45 | <Hixie> | annevk: hmm... "fetch" works by queueing events |
| 09:45 | <Hixie> | er, tasks |
| 09:45 | <Hixie> | not events |
| 09:45 | <Hixie> | forget i said events |
| 09:46 | <Hixie> | annevk: which means you have to spin the event loop to get them |
| 09:46 | <Hixie> | annevk: is the synchronous stuff supposed to block all tasks? |
| 09:46 | <othermaciej> | Hixie: this would be the thread to reply to on rel if you want to make your suggestion: http://lists.w3.org/Archives/Public/public-html/2010Jan/1006.html |
| 09:46 | <annevk> | Hixie, yes |
| 09:46 | <annevk> | Hixie, apart from network tasks |
| 09:47 | <annevk> | Hixie, network tasks are processed to figure out when the request is done |
| 09:47 | <annevk> | Hixie, or to do some kind of timeout fail |
| 09:47 | <Hixie> | annevk: even network tasks relating to other things? |
| 09:47 | <annevk> | Hixie, or follow a redirect, etc. |
| 09:47 | <Hixie> | annevk: e.g. does <img onload> fire during a sync XHR? |
| 09:48 | <annevk> | Hixie, hmm no, that shouldn't happen |
| 09:48 | <othermaciej> | Hixie: or you could respond to the comments on issue 27 here: http://lists.w3.org/Archives/Public/public-html/2010Jan/1399.html |
| 09:48 | <Hixie> | othermaciej: is there corresponding bug? |
| 09:48 | <annevk> | Hixie, only network tasks of the object in question |
| 09:48 | <othermaciej> | Hixie: that issue predates the current process, and I believe there is no bug at all relating to it |
| 09:49 | <Hixie> | othermaciej: sounds like the process is too heavy weight, then. we should just do it in the lightweight bug fashion. I'll respond to the change proposals saying that and proposing we exercise the registry. |
| 09:49 | <Hixie> | annevk: sounds like your life would be better off if in the sync case you just did the fetch manually |
| 09:49 | <Hixie> | annevk: rather than try to use the event loop for everything except the event loop! :-) |
| 09:50 | <othermaciej> | Hixie: sounds ok to me |
| 09:50 | <othermaciej> | and I am fine with using a bug to track the needed change if after exercising the process there's consensus that we should go with it |
| 09:51 | <roc> | woohoo, some open Web motion in China: http://blog.mozilla.com/ligong/2010/02/09/china-construction-bank-supports-firefox/ |
| 09:51 | <annevk> | Hixie, can I convince you to give "fetch" an optional sync flag so that I can use fetch? |
| 09:51 | <annevk> | Hixie, the reason I'm asking is that fetch defines a bunch of things already; having to define all those things again (as I've done now) is a bit of a waste |
| 09:51 | <annevk> | though I suppose I could |
| 09:52 | <Hixie> | annevk: that might work. file a bug? mark it P1 critical if you need it this week rather than just anytime this month. |
| 09:52 | <annevk> | roc, would be interesting to know what they use for Firefox |
| 09:52 | <roc> | yeah |
| 09:52 | <annevk> | roc, do they use <keygen> or some Mozilla proprietary API? |
| 09:53 | <annevk> | ah, you don't know either :) |
| 09:53 | <roc> | I hope not |
| 09:53 | <roc> | even if they do, it's a big step forward from ActiveX |
| 09:53 | <roc> | of course it could also be NPAPI |
| 09:54 | <zcorpan> | maybe they use XBL1 |
| 09:55 | <hsivonen> | it's really sad that it's 2010 and banks support particular browsers |
| 09:55 | <roc> | in China it's not really 2010 :-) |
| 09:55 | <roc> | not on the Web |
| 09:55 | <hsivonen> | roc: It's not 2010 in Danske Bank, either. |
| 09:57 | <annevk> | Hixie, cool, thanks |
| 09:57 | <annevk> | filed |
| 10:13 | <Lachy> | hsivonen, what does Flickr use to "protect" images? I didn't think they did anything like that. |
| 10:15 | <hsivonen> | Lachy: if the user who publishes photos chooses to enable the feature, Flickr disables the "All sizes" button and overlays the photo with a transparent gif |
| 10:15 | <hsivonen> | as a result, browsers offer to save the transparent gif, since it's the frontmost image for any given pixel of the photo |
| 10:16 | <Lachy> | I thought the All Sizes button was just disabled for free accounts. I didn't realise there was an option to disable it manually |
| 10:17 | <hsivonen> | interesting tidbit of the day, there are named character references starting with each of the letters a-z and A-Z |
| 10:17 | <hsivonen> | there are no other start characters for named character references |
| 10:18 | <annevk> | zcorpan, I removed the other filter options |
| 10:19 | <annevk> | zcorpan, until someone complaints |
| 10:19 | <roc> | hmm, so it appears they have in fact wrapped their ActiveX controls in NPAPI |
| 10:19 | <roc> | so it could work cross-browser, but still stuck on Windows :-( |
| 10:19 | hsivonen | is happy to be able to read the spec in Minefield these days without beachballing |
| 10:20 | <MikeSmith> | hsivonen: because of parser changes or other changes? |
| 10:20 | hsivonen | wonders what the situation with banking on mobile devices is in China and South Korea |
| 10:20 | <hsivonen> | MikeSmith: I think both due to parser changes and due to layout changes |
| 10:20 | <MikeSmith> | cool |
| 10:21 | <MikeSmith> | I don't think people actually do any browser-based banking in China and South Korea |
| 10:22 | <hsivonen> | at least with the Danske Bank JNI craziness, you can get around it using the Web bank version meant for mobile devices |
| 10:22 | <MikeSmith> | bank sites as a class are the worst as far as lack of cross-browser support and broken JS and other things |
| 10:22 | <zcorpan> | annevk: ok |
| 10:23 | <MikeSmith> | but airline sites as a class are not far behind |
| 10:24 | <MikeSmith> | I find it not coincidental that airlines are in a class of business that it is known to treat its customers with a relatively higher degree of contempt that most other customer-service businesses |
| 10:24 | <hsivonen> | yeah. Lufthansa should rewrite their seat selector without Flash. |
| 10:24 | <MikeSmith> | banks also operate with a certain amount of contempt toward their average customers |
| 10:25 | <annevk> | zcorpan, I want to remove filter options from the diff page too because they are useless there |
| 10:25 | <annevk> | zcorpan, that's for whenever I have some more free time |
| 10:25 | <hsivonen> | Web bank considerations are a big factor in my bank choice, but my airline choices would become overconstrained if I wanted to avoid both Heathrow and Flash |
| 10:25 | <MikeSmith> | I mean I find it not so coincidental that the same classes of business that are known for poor/contemptuous customer services are also the same ones that try to force their users to use particular browsers and OSes |
| 10:28 | <MikeSmith> | Heathrow is great example of open contempt on a large scale |
| 10:28 | <othermaciej> | roc, annevk: I wish we could standardize some better crypto APIS than just keygen (whether Mozilla's PKI stuff, or something modeled on Microsoft's APIs, or something new) |
| 10:29 | <zcorpan> | annevk: the diff page could have a link back to index |
| 10:29 | <Hixie> | AryehGregor: "A square wheel works, as long as you're willing to do a lot more work" |
| 10:29 | <Hixie> | AryehGregor: you should go to the San Francisco exploratorium, they have a track with a square wheel where the ride is completely smooth :-) |
| 10:30 | <roc> | MikeSmith: there is massive amounts of online banking in China |
| 10:30 | <othermaciej> | yeah, you don't need more work, you just need to make your road a catenary curve |
| 10:30 | <roc> | just not on mobile |
| 10:30 | <Hixie> | AryehGregor: http://en.wikipedia.org/wiki/File:Rolling-Square.gif http://www.americandigest.org/mt-archives/square_wheels.jpg |
| 10:31 | <roc> | othermaciej: the issue here is that the large Chinese banks each have their own USB key storage device, and custom ActiveX controls to talk to those devices |
| 10:31 | <othermaciej> | roc: I see, awesome |
| 10:32 | <roc> | it's pretty dumb |
| 10:32 | <roc> | there is no trusted path to the device, so you don't actually get any protection against malware |
| 10:32 | <othermaciej> | if you ever look at the per-country browser stats from NetApps, China seems to have much more computing monoculture than almost any other country |
| 10:33 | <Philip`> | Before cavemen invented circles, I wonder if they made square wheels and inverted-catenary roads |
| 10:33 | <othermaciej> | the percentages for Windows and for IE are both much higher than anywhere else I could find |
| 10:33 | <roc> | China and South Korea |
| 10:33 | <othermaciej> | (though part of that could have been Maxthon getting counted as IE) |
| 10:33 | <hsivonen> | one *should* count Maxthon as IE |
| 10:34 | <roc> | We should send Li Gong from our Beijing office down to talk to you guys |
| 10:34 | <MikeSmith> | roc: yeah, I was just referring to browser-based banking from mobile devices |
| 10:35 | <othermaciej> | hsivonen: from the perspective of "computing monoculture", that is probably true |
| 10:35 | <roc> | he's been in there for years figuring out the problems and trying to make progress |
| 10:38 | zcorpan | decides to use the indent/outdent feature in fckeditor to be translated into <details> |
| 10:39 | <roc> | one huge problem is that almost every PC comes with CDs full of pirated software |
| 10:39 | hendry | lived in Korea for a year. Also I am helping train some guys from our Taiwan office who find it difficult to think outside Visual Studio. |
| 10:39 | <roc> | if you want distribution your best strategy is to pay to be on those CDs |
| 10:39 | <roc> | along with the malware guys :-( |
| 10:40 | <roc> | another interesting problem is that the "non-IE browser" niche has been partially filled by browsers like Maxthon and others that are just shells around Trident |
| 10:40 | <roc> | they are perceived as non-IE |
| 10:40 | <roc> | better still for them, they are perceived as Chinese-made |
| 10:41 | <roc> | that's in addition to the complete dependence of banking on ActiveX, and on Web sites in general on IE quirks |
| 10:43 | <roc> | it may also be true that Microsoft can get away with certain practices in China that they can't any longer in other countries |
| 10:44 | <roc> | ah well. There is hope. |
| 10:44 | <jgraham> | Mobile is interesting, because Microsoft don't have nearly the same presence there |
| 10:45 | <othermaciej> | true, I have not observed the same kind of monoculture in mobile browsers or operating systems anywhere |
| 10:45 | <roc> | ahem |
| 10:46 | <zcorpan> | hmm, indent used style="" without a wrapper element, so that's not so useful. blockquote probably works better |
| 10:47 | <roc> | Mobile is probably the big hope in China, because ActiveX controls simply won't be a solution there |
| 10:48 | <hendry> | i've seen a couple of Chinese android devices at work. So we can look forward to a webkit monoculture :) |
| 10:48 | <roc> | there are in fact quite a few people looking forward to a webkit monoculture |
| 10:54 | <othermaciej> | there are people who want a webkit monoculture, but even that is less "mono" than an IE monoculture, plus I don't see them getting their wish so far |
| 10:54 | <othermaciej> | Opera is still pretty big in mobile browsing volume |
| 11:04 | <AryehGregor> | Hixie, I would consider making your floor be a precisely-shaped series of inverted catenaries to be "a lot more work". |
| 11:05 | <Hixie> | :-) |
| 11:10 | <AryehGregor> | MikeSmith, http://wiki.whatwg.org/api.php?action=query&prop=revisions&titles=Validator.nu+alt+advice&rvprop=content&rvsection=2 |
| 11:10 | <AryehGregor> | I finally managed to find the API guy and ask him. He's on at different times from you, I guess, so I kept on forgetting. |
| 11:27 | gsnedders | sighs at the es5-discuss emails |
| 11:32 | <MikeSmith> | AryehGregor: nice, thanks |
| 11:33 | <MikeSmith> | hmm, or not, maybe |
| 11:33 | <MikeSmith> | that's just giving the raw wikitext, right? |
| 11:35 | <MikeSmith> | man, subversion never fails to find new ways to be disappointing |
| 11:36 | <MikeSmith> | I'm discovering that once you have a workspace that you've used with a newer version svn client, you can't then go back to using that workspace with an older version of an svn client |
| 11:38 | <othermaciej> | gsnedders: what makes you sigh about them? |
| 11:38 | <othermaciej> | AryehGregor: once you've boiled the ocean, retiling your floor is no big deal |
| 11:38 | <gsnedders> | othermaciej: Well, basically, we have interop on behaviour of \09 and \9, but because the comittiee doesn't like octal escape sequences, we're just going to make them illegal. |
| 11:39 | <AryehGregor> | Yeah, it gives you wikitext. As discussed, it's not obvious what HTML output would be correct. You can feed it back with action=parse: http://wiki.whatwg.org/api.php?action=parse&title=Validator.nu+alt+advice&text=''Foo''; |
| 11:39 | <AryehGregor> | (you might want to POST if you're using lots of text, I guess) |
| 11:39 | <gsnedders> | othermaciej: https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003491.html |
| 11:40 | <othermaciej> | gsnedders: what does it mean to make them "illegal"? will the required behavior for \07 change, or will it be mandatory to reject it, or will it just be "undefined"? |
| 11:40 | <othermaciej> | there's not even a surface-level ECMAScript conformance checker so it's hard to say what is illegal for the language |
| 11:41 | <othermaciej> | (I think maybe there should at least be a checker to verify that your program is correct syntax per the ECMAScript grammar, even though that wouldn't catch many other kinds of undefined constructs) |
| 11:42 | <gsnedders> | othermaciej: Per spec, "\07" does not meet the grammar, except if you allow octals (defined in appendix B). "\08" equally does not match the grammar. |
| 11:42 | <gsnedders> | The problem is the latter case |
| 11:42 | <othermaciej> | I see, so pseudo-octal is the problem? |
| 11:42 | <gsnedders> | Everything treats that as \x008 |
| 11:42 | <gsnedders> | OR octal-followed by non-octal |
| 11:42 | <othermaciej> | and by "problem" I mean not part of the defined grammar and behavior not defined |
| 11:43 | <gsnedders> | The grammar uses lookaheads to forbid it |
| 11:43 | <gsnedders> | So yeah, behaviour is undefined |
| 11:43 | <othermaciej> | gsnedders: if Brendan thinks it's not used on the Web, I kinda wish he would test that with the Mozilla code before failing to spec t |
| 11:43 | <gsnedders> | Whereas if the lookaheads asserting != OctalDigit and not != DecimalDigit, it would match the spec |
| 11:44 | gsnedders | sends email asking when they intend to change Gecko |
| 11:48 | <AryehGregor> | othermaciej, surely you could write a decent ECMAScript validator by just adding extra code to normal JS engines, which (maybe optionally) raise a warning whenever they hit spec violations? |
| 11:48 | <AryehGregor> | Of course, it wouldn't be perfect, but it would catch errors that were actually hit at runtime. |
| 11:49 | <othermaciej> | AryehGregor: the word "just" in your question contains a large assumption |
| 11:49 | <AryehGregor> | That it would be easy to do that? |
| 11:50 | <AryehGregor> | Well, you could presumably offer to raise warnings for at least *some* conformance requirements. |
| 11:50 | <AryehGregor> | Even if most would be hard to check for. |
| 11:50 | <othermaciej> | JavaScriptCore couldn't even easily be used to check the syntax level, since we support many extensions |
| 11:51 | <othermaciej> | so step 1 would be rewriting the tokenizer and parser to remove all grammar extensions |
| 11:51 | <AryehGregor> | Shouldn't those extensions raise warnings as spec violations if used? |
| 11:51 | <AryehGregor> | I guess it's not quite that simple. |
| 11:51 | <AryehGregor> | But it's doable in principle. Gecko is rewriting its HTML parser right now for spec compliance, right? |
| 11:51 | gsnedders | thinks it would be non-trivial even in Carakan without us supporting many extensions |
| 11:52 | <AryehGregor> | Just depends on how much people want it. |
| 11:52 | <gsnedders> | AryehGregor: That doesn't throw warnings on parse errors |
| 11:53 | <AryehGregor> | gsnedders, well, no. It's not meant to. |
| 11:53 | <AryehGregor> | I didn't mean actual browsers should necessarily do JS validation. |
| 11:54 | <AryehGregor> | . . . anyway. |
| 11:54 | <AryehGregor> | No one seems to care about JS spec conformance. |
| 11:54 | <AryehGregor> | I've never even looked at the ES spec. |
| 11:54 | gsnedders | has spent far too much time looking atit |
| 11:55 | gsnedders | really hates it |
| 12:18 | Philip` | wonders where the missing space is meant to occur in "looking atit" |
| 12:21 | <gsnedders> | *at it |
| 12:27 | <Philip`> | Oh |
| 13:34 | <annevk> | Hixie, you are using "Pause until either any applicable style sheets have been fetched and applied, or the user agent has timed out and decided to not wait for those style sheets." |
| 13:34 | <annevk> | Hixie, so is that incorrect too? |
| 13:34 | <annevk> | Hixie, it mixes pause and fetching |
| 13:35 | <annevk> | this stuff is hairy |
| 15:02 | <Dashiva> | "I'm not so concerned about implementers, I'm concerned about people reading just HTML5 and concluding that the spec requires sniffing" |
| 15:02 | <Dashiva> | What is the danger here? |
| 15:04 | <TabAtkins> | You mean, like, what could happen if an author were to somehow read that and gain that impression? |
| 15:04 | <Philip`> | Users might decide that since the spec requires sniffing, it's safe for them to produce content that relies on sniffing |
| 15:04 | <Philip`> | and that would harm the UAs that don't sniff |
| 15:05 | <Dashiva> | The one user doing that seems rather insignificant compared with the thousands of users who don't read the spec, but produce content that requires sniffing anyhow |
| 15:06 | <annevk> | if users read the spec there would be no need for sniffing |
| 15:06 | <hsivonen> | Dashiva: you could point that out in the bug |
| 15:06 | <Philip`> | That's still one user who would benefit from the spec being clear that sniffing is not required (from which they infer that they can't rely on sniffing) |
| 15:06 | <annevk> | because HTTP requires UAs to adhere to the Content-Type currently |
| 15:06 | <Philip`> | (and hence they will produce content that works in more UAs, so everyone wins) |
| 15:07 | <Philip`> | so it's better than nothing |
| 15:07 | <Dashiva> | Philip`: UAs that don't sniff would still be in an equally bad position |
| 15:08 | <Philip`> | They'd be in a marginally better position, and the author would be in a wider marginally better position |
| 15:08 | <Philip`> | and the HTML5 spec is a collection of tens of thousands of things that each make the world only a tiny bit better |
| 15:08 | <Dashiva> | If the author cared about UAs that didn't sniff, he wouldn't make content that relies on sniffing |
| 15:09 | <TabAtkins> | On the other hand, if he thinks that all UAs are required to sniff, then he might not care about ones that don't, as they're non-conformant in his eyes. |
| 15:09 | <Philip`> | If he reads just HTML5 and concludes the spec requires sniffing, then he is more likely to believe there are no UAs that don't sniff |
| 15:10 | <Dashiva> | Surely not |
| 15:10 | <Dashiva> | If he cares about UAs that don't sniff, then he knows about them |
| 15:11 | <Philip`> | That seems untrue |
| 15:11 | <Philip`> | I care a bit about people who visit my sites in browsers I've never even heard of |
| 15:11 | <Philip`> | and search engine crawlers I've never heard of |
| 15:11 | <Philip`> | etc |
| 15:12 | <Philip`> | so I want to make content that is likely to work for them, even if I don't know any details about them |
| 15:13 | <Philip`> | and to some extent I do that based on the assumption that if a spec requires something then these unknown UAs are likely to follow it |
| 15:14 | <Philip`> | (particularly if all desktop browser I test in follow it too) |
| 15:14 | <Philip`> | s//s/ |
| 15:17 | <Dashiva> | Philip`: But that's trivially untrue, since a large amount of tools don't use HTML parsers. |
| 15:19 | <gsnedders> | regexp ftw! |
| 15:20 | <Philip`> | Dashiva: It's an unsafe assumption, but (in the absence of better information) it's the best assumption I can make |
| 15:21 | <Philip`> | I have no idea how Googlebot parses HTML but I assume that if my page is valid HTML and parses correctly in desktop browsers then probably Googlebot will parse it correctly too |
| 15:22 | <Philip`> | and I'll happily omit </p> and <html> tags, and write <br /> etc, based on that assumption |
| 15:25 | <Dashiva> | Philip`: But that changes your assumption. You aren't actually aligning with the spec, but rather with desktop browser behavior |
| 15:27 | <Philip`> | I'm aligning with the information I have available, which consists of the spec plus observable behaviour |
| 15:28 | <Philip`> | If they agree then I'll be reasonably confident in my assumption |
| 15:28 | <Philip`> | But if I conclude from reading the spec that some UAs might not have that behaviour, I'll be much more cautious about assuming it |
| 15:29 | <Dashiva> | Well, the spec says UAs don't have to support text/html, so leaving out </p> will break a class of conforming UAs |
| 15:30 | <zcorpan> | using text/html at all will break a class of conforming UAs (regardless of tags used) |
| 15:31 | <Philip`> | My available information also consists of knowledge that most implementors are not entirely insane, and therefore will attempt to support text/html |
| 15:31 | <Dashiva> | Equally, most implementors are not entirely insane, and will sniff as required |
| 15:32 | <zcorpan> | maybe they'll sniff but not exactly as required |
| 15:32 | <TheOutlawTorn> | Hi |
| 15:32 | <gsnedders> | hi |
| 15:33 | <TheOutlawTorn> | Hi gsnedders |
| 15:33 | <TabAtkins> | Yay for PHP SPL. |
| 15:34 | TabAtkins | just wrote a convenience class for turning mysql results into a tree iterator. |
| 15:35 | <gsnedders> | TabAtkins: The real question is are you dealing with software in which you can rely upon SPL being enabled |
| 15:35 | <TabAtkins> | Yes - it's all personal tools for use on servers I control. |
| 15:36 | <gsnedders> | Ah, that avoids so much of the horribleness of PHP. |
| 15:36 | <TabAtkins> | Yus. |
| 15:38 | gsnedders | founds another crash bug in PHP over the weekend |
| 15:39 | <Philip`> | Is crashing PHP considered to be a bug? |
| 15:40 | <gsnedders> | They are less often closed as bogus |
| 15:42 | <Philip`> | Perl's unpack function lets you read arbitrary integers as pointers, so you can crash it trivially (unless running in a restricted-capability environment), so crashes with easy workarounds (i.e. "don't do that") aren't necessarily serious problems |
| 15:42 | <Philip`> | but crashes in JS implementations would be much more serious because there's different expectations in the environments where they're used |
| 15:43 | <Philip`> | but I don't know which end of the scale PHP asires to |
| 15:43 | <Philip`> | *aspires |
| 15:43 | <gsnedders> | If something relies upon a deprecated option to crash, it might not matter |
| 15:43 | <gsnedders> | Otherwise, it probably does |
| 15:52 | <TheOutlawTorn> | Did any of you made a website recently that does not support 1024 screen resolution? |
| 15:53 | <TabAtkins> | You mean, that is too wide for 1024? |
| 15:54 | <TheOutlawTorn> | I mean that the website will look as it should only at resolution higher than 1024, probabil 1280x768 |
| 15:54 | <TabAtkins> | No, I've never done so. I test my stuff at 1024. |
| 15:54 | <TheOutlawTorn> | I see. |
| 15:55 | <Philip`> | I only test at 1280x800, but I don't have users |
| 15:55 | <TabAtkins> | Which can be annoying sometimes, since all of my monitors are larger than 1024. |
| 15:55 | <TabAtkins> | But I've set up a resize command in Web Developer that helps out, at least. |
| 15:56 | <annevk> | getComputedStyle ... I wish you'd die |
| 15:56 | <annevk> | lalala |
| 15:56 | <TheOutlawTorn> | I finished my website that took a lot of planning since I don't do well at designing, and yesterday when I tested it at 1024 I've discovered that it does not look as it should. |
| 15:56 | <TabAtkins> | annevk: I just... stay far away from that. I rely solely on jQuery to do my CSS parsing for me. Shrug. |
| 15:56 | <TheOutlawTorn> | I thought for a min not to support 1024 but I don't know how smart is that. |
| 15:57 | <TabAtkins> | There's still lots of people at 1024. |
| 15:57 | <TabAtkins> | So it depends on if you care about them or not. |
| 15:57 | <TheOutlawTorn> | Indeed there are. |
| 16:00 | <TheOutlawTorn> | Better offer support if I think about it, it's just about resizing an image and displaying a different stylesheet after all. |
| 16:00 | <TabAtkins> | Use media queries! |
| 16:01 | <TheOutlawTorn> | I thought of doing it with php since I don't know javascript |
| 16:01 | <TabAtkins> | Media queries are CSS, actually. |
| 16:01 | <annevk> | actually, they're not |
| 16:01 | <TabAtkins> | http://www.w3.org/TR/css3-mediaqueries/ |
| 16:02 | <TheOutlawTorn> | lol |
| 16:02 | <TabAtkins> | Then why are they in a CSS spec, smartypants? ^_^ |
| 16:02 | <TheOutlawTorn> | I doubt that all the users using 1024 will have a modern browser. |
| 16:02 | <TheOutlawTorn> | I bet a lot of them still use ie6 |
| 16:02 | <Philip`> | Not everyone has their browser fullscreen |
| 16:02 | <TabAtkins> | Sure, but everyone hates ie6 users. |
| 16:03 | <TheOutlawTorn> | :) |
| 16:03 | <Philip`> | People on larger screens might have multiple browser windows and preferably your page should work sensibly when they make the windows smaller |
| 16:03 | <TheOutlawTorn> | I hate IE users in general. |
| 16:03 | <Philip`> | I hate users in general |
| 16:04 | <daedb> | No version of IE supports media queries. |
| 16:04 | <TabAtkins> | That's the spirit, Philip`. |
| 16:04 | <TheOutlawTorn> | I didn't thought about what you just said, I guess I still need to do some tests before I can call it finished. |
| 16:05 | <TheOutlawTorn> | Hate is what keeps the world moving, never stop hating. |
| 16:07 | <TabAtkins> | Yay SPL again. |
| 16:07 | TabAtkins | just wrote a useless class that lets him iterate through the fibonacci sequence. |
| 16:07 | <TheOutlawTorn> | Why? |
| 16:07 | <TabAtkins> | Just to play around. |
| 16:07 | <TabAtkins> | Using the Iterator interface. |
| 16:08 | <TheOutlawTorn> | Hm |
| 16:08 | <gsnedders> | TabAtkins: That's not SPL |
| 16:08 | <TabAtkins> | foreach(new LimitIterator(new Fib,0,20) as $fib){ echo $fib."<br>"; } |
| 16:08 | <TabAtkins> | Mang, whatever. |
| 16:08 | <Philip`> | Why not just write a function that returns it in constant time for any arbitrary index? |
| 16:09 | <TabAtkins> | Because that's silly, Philip`. |
| 16:09 | <gsnedders> | TabAtkins: http://se2.php.net/manual/en/class.iterator.php#91068 |
| 16:09 | <Philip`> | It's just http://upload.wikimedia.org/math/9/6/8/968be88f42e32712cb10d89a765ce708.png and you save all the effort of iteration |
| 16:10 | <TabAtkins> | gsnedders: Yeah, I know it's a common toy. ^_^ |
| 16:10 | <gsnedders> | TabAtkins: I was just playing around with infinite iterators :P |
| 16:11 | <TabAtkins> | Philip`: That looks to have relatively hefty constant factors. If I want the fib sequence starting from the beginning, iteration is cheaper. |
| 16:11 | <TabAtkins> | gsnedders: Oh, haha, didn't see that was you who made the comment. |
| 16:11 | <gsnedders> | TabAtkins: :) |
| 16:11 | <gsnedders> | TabAtkins: I have written a fair bit of PHP :) |
| 16:11 | <TabAtkins> | Yeah, I know. |
| 16:12 | <gsnedders> | ]http://github.com/gsnedders/complexpie — what I've been touching recently |
| 16:12 | <TabAtkins> | It's my main language at this point, unfortunately. |
| 16:12 | <Philip`> | TabAtkins: It's two pows and a subtraction and a division - that's going to be far cheaper than even just printing the output :-) |
| 16:12 | TabAtkins | needs to get Lisp running on his webserver. |
| 16:12 | <TabAtkins> | Philip`: Bah! |
| 16:12 | <Philip`> | Admittedly you might get problems with the finite precision of floating point numbers |
| 16:13 | <TabAtkins> | Yeah, was just typing that it requires an accurate expansion of phi, which itself uses sqrt(5) in its definition. |
| 16:14 | <TabAtkins> | On that note: http://www.facebook.com/photo.php?pid=3458694&id=707492809&comments&alert |
| 16:15 | <TabAtkins> | (Dunno how widely viewable that is.) |
| 16:30 | <TabAtkins> | Bwahaha, the text-wrapping on my company's site means that, at the precise size that my IE window opened up at, we proclaim that we have "The World's Largest Member". |
| 16:30 | <TabAtkins> | And that size is 800x600. Glorious. |
| 16:30 | <annevk> | TabAtkins, the css3- prefix is a historical accident |
| 16:30 | <annevk> | TabAtkins, much like it is with Selectors |
| 16:31 | <annevk> | TabAtkins, anyway, ask the TAG, URIs have no meaning |
| 16:31 | <TabAtkins> | I know. ^_^ My point, though, was that it didn't have anything to do with javascript, which seemed to be TheOutlawTorn's concern. |
| 16:33 | <TheOutlawTorn> | Well anyways I think it's best to use js since that's really easy to accomplish. |
| 16:33 | <TheOutlawTorn> | And I think it would be also good to start learning js at this point. |
| 16:34 | <TabAtkins> | It is a good idea. Go learn jQuery, though. Your life will be made infinitely easier. |
| 16:34 | <annevk> | wait what? |
| 16:34 | <annevk> | js is really easy but you don't actually know it? |
| 16:34 | <TheOutlawTorn> | That is a javascript library |
| 16:34 | <gsnedders> | TabAtkins: You've never tried to debug random objects becoming undefined in jQuery obviously |
| 16:34 | <TheOutlawTorn> | annevk: I never actually wanted to learn it in the first place. |
| 16:35 | <TabAtkins> | gsnedders: No. I have never had such a problem. |
| 16:35 | <gsnedders> | TabAtkins: See, you obviously need to do more browser QA on buggy JS engines :P |
| 16:35 | <TabAtkins> | TheOutlawTorn: Yeah, I know. I mean, though, that jQuery makes javascript development infinitely easier. |
| 16:35 | <TheOutlawTorn> | Yeah, I heard.. |
| 16:36 | <TabAtkins> | I think I need to *not* do that, gsnedders ^_^. |
| 16:37 | <gsnedders> | TabAtkins: :) |
| 16:43 | <TabAtkins> | Actually, that's a good reason to avoid joining the Chrome team fully, and instead just using them as a 20% project to implement CSS specs. |
| 16:44 | <TheOutlawTorn> | ? |
| 16:44 | <TabAtkins> | That way I don't have to ever go debug random js engine things. |
| 16:45 | TabAtkins | just got hired by Google and hasn't yet gotten to the point where he decides what team to join. |
| 16:46 | <gsnedders> | heh |
| 16:46 | <Philip`> | You should join the secret Evil team |
| 16:46 | <TabAtkins> | Hey, if they offer... |
| 16:50 | <jgraham> | TabAtkins: Oh, congratulations |
| 16:51 | <TabAtkins> | Thanks, jgraham. ^_^ |
| 16:51 | <jgraham> | Did you announce that already? I missed it if so |
| 16:51 | <TabAtkins> | I'd talked about it before, but I don't think many people were around then. I wasn't sure I'd be able to accept at that point. |
| 16:54 | <jgraham> | So you are working mainly on specs, or mainly on products? |
| 16:54 | <TheOutlawTorn> | Congratulations. |
| 16:55 | <jgraham> | (well I guess you just said you don't know) |
| 16:55 | <TabAtkins> | jgraham: My intention is to join the Open Source office with Hixie, and work on CSS specs. |
| 16:55 | <TheOutlawTorn> | They let you choose what team you wanna be a part of? |
| 16:55 | <TabAtkins> | TheOutlawTorn: Yeah, several teams pitch themselves at you, and you pick which you'd prefer to work with. |
| 16:56 | <TheOutlawTorn> | Interesting |
| 16:56 | <TheOutlawTorn> | What team has the most members? |
| 16:56 | <TabAtkins> | No clue. |
| 16:57 | Dashiva | wonders why thunderbird thinks "received:" headers are useful to normal people |
| 16:57 | <jgraham> | TabAtkins: Nice |
| 16:57 | <TheOutlawTorn> | Where are you from? If you don't mind me asking. |
| 16:57 | <TabAtkins> | Houston |
| 16:57 | <TheOutlawTorn> | Nice. |
| 16:57 | <jgraham> | You don't fancy moving to California? |
| 16:57 | <TabAtkins> | (Since this is my real name, it's not like there's any real privacy involved. ^_^) |
| 16:58 | <TabAtkins> | Nah, we're moving next month. |
| 17:01 | TabAtkins | wonders if there's any good way to expose depth information from his tree iterator in a foreach loop. Maybe as the key? |
| 17:02 | <gsnedders> | Tree iterator for what? |
| 17:03 | <TabAtkins> | The one that I just wrote. Iterates through a hierarchical collection of mysql rows, turning it into a RecursiveIterator suitable for passing to RecursiveIteratorIterator. |
| 17:03 | <Philip`> | TabAtkins: Set a global variable |
| 17:04 | <Dashiva> | RecursiveIteratorIterator doesn't sound like a class that should exist outside parody |
| 17:04 | <TabAtkins> | Dashiva: Heh, I know. It's kinda rediculous. |
| 17:05 | <Dashiva> | Although I've taken a MMI course where the prof had classes like SliderSliderSliderInputExample |
| 17:05 | <TabAtkins> | But it transforms a RecursiveIterator into a linear iterator, so you don't have to deal with maintaining a stack as you descend through children yourself. |
| 17:05 | <Philip`> | Does it use a RecursiveIteratorIteratorFactory? |
| 17:05 | <TabAtkins> | Luckily, no. |
| 17:05 | jgraham | is just staring wide-mouted at the IRC channel |
| 17:06 | <jgraham> | *mouthed |
| 17:06 | <jgraham> | RecursiveIteratorIterator? Seriously? |
| 17:06 | <TabAtkins> | (I attached a static function to the class that takes the same arguments as the constructor, which just returns a RecursiveIteratorIterator so I don't have to type that myself.) |
| 17:06 | <Dashiva> | So that class implements RecursiveIteratorIteratorFactory via duck typing |
| 17:07 | <TabAtkins> | jgraham: http://php.net/manual/en/class.recursiveiteratoriterator.php |
| 17:08 | <jgraham> | I refuse to be dirtied by reading the PHP manual |
| 17:08 | <gsnedders> | jgraham: Welcome to PHP. |
| 17:08 | <TabAtkins> | Hahaha. |
| 17:08 | <gsnedders> | jgraham: Oh, come on. That's quite good by PHP standards. |
| 17:08 | <TabAtkins> | Nod. It |
| 17:08 | <TabAtkins> | It's at least consistently named. |
| 17:10 | <Philip`> | It's like they decided to copy the irritating parts of Java |
| 17:10 | <Sidnicious> | PHP: If you don't think it's built in, you haven't spent enough time reading the docs. |
| 17:10 | <AryehGregor> | Practically nothing is reliably built into PHP, that's one of the most obnoxious things about it. |
| 17:11 | <TabAtkins> | The difficulty is just in parsing it. It's (RecursiveIterator)Iterator; that is, an iterator over a recursive iterator. |
| 17:11 | <Dashiva> | $fileSPLObjects = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($directory), RecursiveIteratorIterator::CHILD_FIRST); |
| 17:11 | <TabAtkins> | Transforming a tree-like structure back into a list-like structure, so you can just hand it to the foreach() loop. |
| 17:11 | <Dashiva> | It's like I'm really using Java! |
| 17:11 | <Philip`> | I was just about to paste exactly that line :-( |
| 17:12 | <Dashiva> | Finally, I beat Philip` at something. |
| 17:13 | <gsnedders> | Dashiva: congrats! |
| 17:13 | <JonathanNeal> | What would you guys recommend as Windows sotware to convert mp4's to ogv's? |
| 17:13 | <Philip`> | use File::Find; find(sub { print "Found $_\n"; }, $directory); |
| 17:14 | <Dashiva> | Philip`: Can you fix LWP so it uses the right content-type? |
| 17:14 | <Philip`> | What is "right"? |
| 17:14 | <Philip`> | Also, what is wrong? |
| 17:15 | <Philip`> | Do you want it to not look at <meta> or something? |
| 17:15 | <Philip`> | (That's the biggest annoyance I've encountered) |
| 17:15 | <Dashiva> | Well, partially |
| 17:15 | <Dashiva> | I want it to not look at meta if there is a HTTP header |
| 17:15 | <Dashiva> | Like HTML5 (and HTML4) says |
| 17:16 | <Dashiva> | And additionally, it looks like the most recent LWPs use the first HTTP header instead of the last |
| 17:16 | <JonathanNeal> | I was hoping to convert videos over to ogv for Firefox <video> support. |
| 17:18 | <TabAtkins> | Google is unhelpful, JonathanNeal. Shrug. |
| 17:18 | <JonathanNeal> | I know, that's why I came here. |
| 17:18 | <daedb> | Firefogg? |
| 17:19 | <AryehGregor> | Yeah, you could use Firefogg. |
| 17:19 | <AryehGregor> | Results when encoding H.264 -> Theora are not going to be great, though; conversions between different types of lossy formats never are. |
| 17:19 | <Dashiva> | I remember seeing some awesometastic transcoding anything-to-anything app, but I forgot the name |
| 17:20 | <AryehGregor> | You can also use ffmpeg2theora, according to this: http://diveintohtml5.org/video.html |
| 17:20 | Dashiva | wonders what will happen when there's a ffmpeg2. Will there be a ffmpeg22theora? |
| 17:21 | <JonathanNeal> | haha |
| 17:21 | <TabAtkins> | This is why programming languages should stop reserving so much syntax. ffmpeg->theora is much better. |
| 17:21 | <TabAtkins> | Or the actual unicode arrow. |
| 17:21 | <JonathanNeal> | Do you guys think mp4 support is in the future of Firefox? |
| 17:21 | TabAtkins | keeps forgetting to mod his keyboard to output the unicode arrows. |
| 17:22 | <AryehGregor> | TabAtkins, you want to actually type a Unicode arrow when you want to invoke the program? |
| 17:22 | <TabAtkins> | YES. |
| 17:22 | <AryehGregor> | Also, ffmpeg->theora = output of command "ffmpeg-" redirected to file "theora". |
| 17:23 | <TabAtkins> | Ys, because silly languages reserve so many symbols for their syntax. |
| 17:23 | <Dashiva> | Can you put theora inside a mp4 container? |
| 17:23 | <AryehGregor> | ffmpeg→theora should be a perfectly good command name, though. |
| 17:23 | <TabAtkins> | Lisp keeps it to a minimum. ()#'`, is all. |
| 17:23 | <AryehGregor> | bash reserves everything and its brother. |
| 17:23 | <Sidnicious> | APL tried this: http://www.wickensonline.co.uk/apl/unicomp-apl-top-large.jpg |
| 17:23 | <Dashiva> | #bash-2.0# brother: reserved name |
| 17:24 | <TabAtkins> | When you're limited to ascii, at least use camelCasing. |
| 17:24 | <TabAtkins> | ffmpegToTheora |
| 17:24 | <JonathanNeal> | AryehGregor, yes if we had those arrows on our keyboards. |
| 17:24 | <TabAtkins> | I mean, english letters and numbers. |
| 17:24 | <Dashiva> | TabAtkins: That insults the design sense of people who prefer lowercasenames |
| 17:24 | <TabAtkins> | Dashiva: Those people can die in a fire. |
| 17:24 | <Dashiva> | They can, but I don't think they will |
| 17:24 | <JonathanNeal> | A dash never killed anyone either. |
| 17:24 | <AryehGregor> | JonathanNeal, Ctrl+Shift+u2192, not too hard to remember. |
| 17:25 | <Dashiva> | Dash is overloaded as minus, bad story there |
| 17:25 | <TabAtkins> | JonathanNeal: Yeah it does. Stupid inline minus operator. |
| 17:25 | <AryehGregor> | TabAtkins, camel-casing is contrary to Unix conventions dating to before both of us were born. |
| 17:25 | TabAtkins | uses dashes in all his Lisp stuff, as is appropriate Lisp style. |
| 17:25 | <Dashiva> | Unix "conventions" |
| 17:25 | <JonathanNeal> | TabAtkins, oh. |
| 17:25 | <JonathanNeal> | An underscore never hurt anyone. |
| 17:25 | <Dashiva> | That's sort of like microsoft "open standards" |
| 17:25 | <AryehGregor> | Pretty sure "foo2bar" has been well established for an awfully long time. |
| 17:25 | <TabAtkins> | AryehGregor: Those conventions are silly. |
| 17:25 | <TabAtkins> | As demonstrated by ffmpeg22theora |
| 17:26 | <jgraham> | TabAtkins: You know, sounding grumpy won't convert more people to lisp ;) |
| 17:26 | <TabAtkins> | I'm not trying to convert anyone. ^_^ |
| 17:26 | <Dashiva> | So atoi should be a2i |
| 17:26 | <AryehGregor> | It would just still be called ffmpeg2theora. |
| 17:27 | <AryehGregor> | Why would you change the name of the command for a new version? |
| 17:27 | <Dashiva> | Maybe ffmpeg and ffmpeg2 aren't compatible |
| 17:27 | <TabAtkins> | What, and use flags to tell it that you're passing an old version? |
| 17:27 | <AryehGregor> | What? |
| 17:28 | <AryehGregor> | Why wouldn't the command-line syntax remain compatible across versions? |
| 17:28 | <AryehGregor> | Or at least compatible enough to give it the same name? |
| 17:28 | <jgraham> | There are lots of much sillier unix things than the naming conventions |
| 17:28 | <TabAtkins> | So then flags to tell it you're passing a new version? |
| 17:28 | <AryehGregor> | What does "passing a new version" mean? |
| 17:28 | <jgraham> | Like the total lack of a standardised way of telling what flag a program accests |
| 17:28 | <jgraham> | *accepts |
| 17:29 | <Dashiva> | I hear make is going to start supporting general whitespace before 2072 |
| 17:29 | <TabAtkins> | ffmpeg versus ffmpeg2 (assuming they're incompatible for some reason) |
| 17:29 | <AryehGregor> | ffmpeg is a piece of software. You don't "pass" it, you're calling it. |
| 17:29 | <AryehGregor> | jgraham, you mean --help isn't good enough? That's not *quite* universal, I'll grant, but it works pretty reliably. |
| 17:29 | <TabAtkins> | Gah, pedantry. You know what I mean. |
| 17:29 | <Dashiva> | AryehGregor: Except when it's only -h |
| 17:30 | <AryehGregor> | TabAtkins, no I don't. I have no idea what you're talking about. Why would you even have the old version installed alongside the new version? If you do, you can use the full path, weirdo. |
| 17:30 | <jgraham> | AryehGregor: That's not enough for e.g. command line completionto work without insane hacks |
| 17:30 | <AryehGregor> | Dashiva, yes, but then usually it says "unrecognized option -" and prints a usage summary anyway. |
| 17:30 | <AryehGregor> | jgraham, programs can provide custom command-line completion if they want, there's a standard way to do that. |
| 17:30 | <Dashiva> | Unless it's a helpful program that ignores unrecognized flags |
| 17:30 | <AryehGregor> | apt-get inst<Tab> -> apt-get install |
| 17:31 | <AryehGregor> | Dashiva, yes, there are a few of those, and they should die in fire. |
| 17:31 | <Dashiva> | -v is also a popular flag to overload |
| 17:31 | <AryehGregor> | Everyone on Linux should follow the GNU command-line argument conventions, period. |
| 17:31 | <jgraham> | AryehGregor: [citation needed] |
| 17:32 | <Dashiva> | AryehGregor: So linux should be incompatible with other *nixes? |
| 17:32 | <AryehGregor> | jgraham, typing "apt-get inst<Tab>" on stock Ubuntu isn't good enough evidence for you? |
| 17:32 | <jgraham> | I was under the impression that those completions were hardcoded in shell-specific scripts |
| 17:32 | <AryehGregor> | Dashiva, no, they should use the same conventions too. |
| 17:32 | <AryehGregor> | jgraham, shell-specific, maybe. I don't know. |
| 17:33 | <jgraham> | Not that the shell could parse out the command line options from the binary somehow |
| 17:33 | <AryehGregor> | Well, obviously not, but there's a format that you can use to achieve the same effect. |
| 17:33 | <AryehGregor> | Often you want more complicated autocompletion anyway. |
| 17:33 | <jgraham> | AryehGregor: This is roughly my definition of "insane hacks" |
| 17:33 | <AryehGregor> | E.g., only autocomplete to files that exist *and* make sense for the command. |
| 17:34 | <AryehGregor> | Your way isn't flexible enough, you need to support scripted autocomplete to get full functionality anyway. |
| 17:34 | <Dashiva> | jgraham: Surely metadata never becomes out of sync with the binaries |
| 17:34 | <AryehGregor> | Dashiva, pretty rarely, when you use package managers. |
| 17:35 | <Dashiva> | Because the people in charge of packages never make mistakes |
| 17:35 | <AryehGregor> | No, but you're inventing unreasonable hypotheticals at this point instead of pointing out real-world problems. |
| 17:35 | <jgraham> | less /etc/bash_completion looks kinda crazy |
| 17:35 | <AryehGregor> | I guess the completion rules are bash-specific. |
| 17:36 | <AryehGregor> | If so, that's kind of lame. |
| 17:36 | <AryehGregor> | Wait a minute, these autocomplete rules are all stored in one big file? |
| 17:36 | <AryehGregor> | Ah, there's also bash_completion.d/. |
| 17:37 | <AryehGregor> | That's a perfectly good Unix-style convention: implement potentially complicated functionality using a shell script you include with your program. |
| 17:37 | <AryehGregor> | I don't see a better proposal from you that's as flexible. |
| 17:38 | <jgraham> | Embed the same information in the binary in a format that can be parsed out |
| 17:38 | <AryehGregor> | Why? |
| 17:38 | <AryehGregor> | You'd have to use a scripting language anyway. |
| 17:38 | <Dashiva> | Looks like a lot of hardcoding inside bash_completion... |
| 17:39 | <AryehGregor> | Dashiva, some core programs seem to be there, /etc/bash_completion.d/ lets other programs add their own stuff, in typical Unix (or at least Linux) fashion. |
| 17:39 | <Dashiva> | freeamp is a core program? |
| 17:40 | <AryehGregor> | Hmm. Suppose not. |
| 17:40 | <Dashiva> | Heh, acroread is there. I guess they're anticipating installs :) |
| 17:40 | <AryehGregor> | I guess it's easier to stick it there than have a whole new file. |
| 17:41 | <TabAtkins> | Yay, it was trivial to hack a depth tracker into the SQLTree class, and just return it as the key of each value. |
| 17:51 | <Philip`> | Dashiva: ffmpeg has only done about one release in its entire history, and that was version 0.5, so I think we've got plenty of time before worrying about version 2 |
| 18:01 | <hober> | It's nice to read something about how people *like* Hixie's spec-writing style for a change: http://bitworking.org/news/2010/02/joel-in-a-box |
| 18:03 | <gsnedders> | RFC 5023 is APP, right? |
| 18:04 | <Philip`> | Google says yes |
| 18:04 | gsnedders | sighs at the sheer number of RFCs he knows the numbers for |
| 18:06 | <gsnedders> | TabAtkins: http://github.com/gsnedders/complexpie/blob/master/src/cachearray.php — fun with PHP! |
| 18:07 | <gsnedders> | (complete with my own very naïve GC impl within PHP!) |
| 18:07 | <TabAtkins> | Yay! |
| 18:08 | <gsnedders> | (basically for static variable caches within functions to avoid computing stuff all the time, and with GC to stop it from growing to really large amounts of memory) |
| 18:08 | <gsnedders> | (the GC is really too naive though, I expect, but it gets pretty good cache hit rates) |
| 18:09 | <gsnedders> | (compared with having no GC whatsoever) |
| 18:10 | <gsnedders> | (there again, for it to be worthwhile to still have the cache, the GC needs to be really cheap) |
| 18:11 | <TabAtkins> | Ah, so a helper for manually implementing memoization. Cool. |
| 18:13 | <Philip`> | How does that actually cache anything? |
| 18:13 | <Philip`> | It looks like it's deferring to the parent all the time, and never returning anything from a cache |
| 18:14 | <TabAtkins> | It's an ArrayObject, which has an internal array backing. |
| 18:14 | <TabAtkins> | And uses parent::offsetGet and parent::offsetSet to actually do the storing/retrieving. |
| 18:14 | <gsnedders> | TabAtkins: Yeah, basically |
| 18:14 | <TabAtkins> | It just wraps gc around it. |
| 18:15 | <Philip`> | Hmm, so this code isn't actually caching anything, it's more of a SelfCleaningArray? |
| 18:15 | <gsnedders> | TabAtkins: Indeed, and offsetExists is deliberately not overridden to keep it quicker |
| 18:15 | <gsnedders> | Philip`: yeah |
| 18:15 | <TabAtkins> | It's meant for *other* things to use it for caching. |
| 18:15 | <gsnedders> | http://github.com/gsnedders/complexpie/blob/master/src/iri.php#L788 |
| 18:15 | <gsnedders> | for example |
| 18:16 | <TabAtkins> | function foo(){ static $cache = new CacheArray; } |
| 18:16 | <gsnedders> | (it turns out doing IRI processing is amazingly expensive) |
| 18:16 | <gsnedders> | TabAtkins: That's invalid syntax, you can't set a new object like that |
| 18:16 | <TabAtkins> | Sure you can. |
| 18:17 | <TabAtkins> | As long as your constructor can be called with no args. |
| 18:18 | <TabAtkins> | Frex, I use foreach(new UserList as $user){} all over my code. |
| 18:18 | <gsnedders> | TabAtkins: Parse error: syntax error, unexpected T_NEW |
| 18:18 | <gsnedders> | TabAtkins: That's totally different |
| 18:18 | <gsnedders> | TabAtkins: It's the fact it's on the RHS of a static dfn |
| 18:19 | <Philip`> | Seems like a weird cache eviction policy |
| 18:19 | <Philip`> | If you access "x" 100 times, then "y" once, then "x" 99 times, it will throw away "x" and keep "y"? |
| 18:19 | <gsnedders> | TabAtkins: http://pastebin.ca/1791616 |
| 18:19 | <gsnedders> | Philip`: I said naïve for a reason |
| 18:20 | <Philip`> | Naive is different to stupid ;-) |
| 18:20 | <gsnedders> | patches welcome :) |
| 18:20 | <gsnedders> | (provided they don't make the getter in the general case more expensive) |
| 18:20 | <TabAtkins> | Ah, is that something special just for static vars? |
| 18:21 | <gsnedders> | TabAtkins: static and global, IIRC |
| 18:21 | <gsnedders> | TabAtkins: It's a property of the keywords |
| 18:21 | <TabAtkins> | How weird. |
| 18:21 | <gsnedders> | TabAtkins: Same applies for public $foo = 'bar'; in a class dfn |
| 18:21 | <Philip`> | LRU would probably the most common arguably-naive algorithm, I guess |
| 18:21 | <TabAtkins> | Okay, well, I use static vars very rarely. |
| 18:22 | <gsnedders> | Philip`: The aim was more some fairly basic LFU |
| 18:23 | <gsnedders> | With a really bad LFU-aging impl |
| 18:25 | <TabAtkins> | You could perhaps drop $oldaccess, and just determine what to drop based on $access. |
| 18:25 | <TabAtkins> | Perhaps just array_slice($access,0,80) to allow young accesses to stick around. |
| 18:25 | <gsnedders> | I could just move over to LRU, but I don't think that's very good for what I need |
| 18:26 | <gsnedders> | e.g., given parsing a URL like '/', it may in general come up a lot, but in one file I get a thousand unqiue other items. I don't want to push that out of the cache |
| 18:27 | <gsnedders> | There's a very long tail for this from the data set I was testing with, so caching that tail doesn't gain much |
| 18:27 | <gsnedders> | What is important is you get the high priority things |
| 18:27 | <gsnedders> | Which is why I really want some sort of LFU impl |
| 18:27 | <Philip`> | If it comes up a lot, it will always be recently used, and you'd only push it out of the cache for the duration of that one file where it's not used |
| 18:27 | <TabAtkins> | Okay, then just cut things based on array_count_values( |
| 18:27 | <TabAtkins> | $access) |
| 18:28 | <Philip`> | Things that are used frequently are used recently |
| 18:28 | <gsnedders> | Philip`: It's a question of whether I want to push it out for that one file, whether I gain anything by losing that cache |
| 18:28 | <Philip`> | Also, RAM is cheap so make the cache much bigger :-) |
| 18:28 | <gsnedders> | Philip`: PHP often runs with small memory limits |
| 18:29 | <Philip`> | I suppose PHP isn't clever enough to have weak references |
| 18:29 | <gsnedders> | It isn't, sadly. |
| 18:29 | <Philip`> | Does it throw an exception when you run out of memory, or just crash? |
| 18:29 | <TabAtkins> | Exception, usually. |
| 18:29 | <TabAtkins> | Sometimes just a crash. |
| 18:29 | <gsnedders> | Throws E_ERROR, a non-catchable error. |
| 18:29 | <Philip`> | That's not so helpful |
| 18:30 | <gsnedders> | Indeed. The only option for keeping caches within a sane size is something like this. |
| 18:31 | gsnedders | does still use an unbound (direct associative array) cache in one place, but where it grows to a certain size and stops growing due to the nature of the cache |
| 18:31 | <gsnedders> | (and where any indirection to another PHP function call is too expensive to be worthwhile even having the cache) |
| 18:59 | <jgraham> | You know you have been using computers in general, and irc in particular, too long when you can't remember what normal people say when they mean "ping" |
| 19:00 | <AryehGregor> | Normal people say "ping"? Other than as part of "ping-pong"? |
| 19:00 | <jgraham> | No, they don't, that's the point |
| 19:00 | <AryehGregor> | Oh. |
| 19:00 | <AryehGregor> | So, uh, how can they mean anything when they say it, if they don't say it? |
| 19:00 | <othermaciej> | "hello" |
| 19:01 | <gsnedders> | AryehGregor: It's the noise you get when the touch a glass in a certain way! |
| 19:01 | <othermaciej> | AryehGregor: "say when they mean", not "mean when they say" |
| 19:01 | <jgraham> | They don't say it. But they say things with similar meanings |
| 19:01 | <AryehGregor> | Oh, I see. |
| 19:01 | <wycats> | question: why does CORS not support unfettered HTTP requests in non-credentialed mode? |
| 19:01 | <AryehGregor> | I misread. |
| 19:01 | <othermaciej> | i.e. instead of saying "ping" to get someone's attention, face-to-face or over the phone the standard protocol is to say "hi" or "hello" |
| 19:02 | <AryehGregor> | I suppose they say "Excuse me" or "Are you there" or such? |
| 19:02 | <othermaciej> | people who are not geeks probably say "are you there" or "ayt" over IM-type communication channels |
| 19:02 | <jgraham> | In context the word I needed was really "remind" |
| 19:03 | <jgraham> | (but that doesn't make sense in general) |
| 19:03 | <AryehGregor> | Ah, like as a transitive verb. |
| 19:03 | <othermaciej> | oh, as in "can you ping her about that" |
| 19:03 | <jgraham> | Yes |
| 19:38 | <hsivonen> | oh great. HTML5 parsing seems to make tests from the W3C DOM Level 1 test suite fail |
| 19:38 | <hsivonen> | oops |
| 19:38 | <hsivonen> | the test had been modified from the W3C original based on an old snapshot of HTML5 |
| 19:38 | <hsivonen> | now I need to change it back |
| 20:00 | <wycats> | so why does uncredentialled CORS still require approval to make the request? |
| 20:01 | <Philip`> | To stop pages from arbitrarily reconfiguring the user's router on http://192.168.0.1, perhaps? |
| 20:01 | <othermaciej> | wycats: for "simple requests" it doesn't require approval to make the request, just to read the results |
| 20:01 | Philip` | may be misunderstanding the question |
| 20:02 | <othermaciej> | for non-simple requests, there is at least the risk of exposing servers behind firewalls to CSRF (beyond what is possible with cross-site form submission) |
| 20:06 | <wycats> | othermaciej: why is approval required to read the requests? |
| 20:06 | <wycats> | without credentials == no CSRF, no? |
| 20:06 | <wycats> | othermaciej: I'm curious why there's no "safe" API to make an HTTP request that doesn't expose any security issues |
| 20:07 | <othermaciej> | wycats: you can't use CSRF to read a resource served from another server, whether with or without credentials |
| 20:07 | <othermaciej> | wycats: in intranets, there are servers where the only "credential" required to access them is being behind the firewall, which is a credential XHR can't remove |
| 20:08 | <wycats> | othermaciej: isn't this something UAs can handle? |
| 20:08 | <wycats> | and behind the firewall people can lock down the credential? |
| 20:09 | <wycats> | othermaciej: in practice, this means that I can't use certain public APIs until people get around to supporting CORS :/ |
| 20:09 | <othermaciej> | wycats: what I'm saying is, there's servers behind firewalls containing confidential information that require no explicit credential to access |
| 20:09 | <othermaciej> | their only protection is being behind a firewall |
| 20:09 | <wycats> | othermaciej: right... and people can already get that info by installing a native app |
| 20:09 | <wycats> | the way around that is permissions |
| 20:10 | <wycats> | so UAs can allow the "corporate security" to disallow access |
| 20:10 | <othermaciej> | wycats: browsing to a web page in your browser should not be equivalent to installing a native app |
| 20:10 | <wycats> | of course not |
| 20:10 | <wycats> | but making an HTTP GET request is a reasonable thing to be able to do |
| 20:10 | <wycats> | in the vast majority of cases |
| 20:11 | <othermaciej> | and indeed the spec lets you make such a request, just not read the result unless the server opts in |
| 20:12 | <wycats> | othermaciej: in general, getting the results of an HTTP request is not considered a secure transaction |
| 20:13 | <othermaciej> | browsers enforce the same-origin security model and therefore have created the expectation that it is, in the browser context |
| 20:15 | <wycats> | brb |
| 20:48 | <zcorpan> | TabAtkins: congrats |
| 20:48 | <TabAtkins> | Thanks, zcorpan. |
| 20:54 | <TheOutlawTorn> | Hello |
| 21:13 | <wycats> | othermaciej: back |
| 21:42 | <zcorpan> | why can't css transitions transition to height:auto |
| 21:42 | <zcorpan> | how are submenus or <details> supposed to have a nice animation with height:auto? |
| 21:43 | <othermaciej> | CSS transitions should totally transition to (and from) height: auto |
| 21:44 | <othermaciej> | I think it does not work right now because it would have to do an extra layout at the end state to figure out how to animate |
| 21:44 | <othermaciej> | or something |
| 21:44 | <othermaciej> | I'm wondering if I can figure out another way to implement <details> nicely w/ mostly just CSS |
| 21:45 | <zcorpan> | webkit animates to height:0 and then snaps over to auto |
| 21:45 | <zcorpan> | opera doesn't animate at all |
| 21:45 | <wycats> | zcorpan: sounds like an impl bug |
| 21:45 | <othermaciej> | I think the spec actually doesn't define animating to/from auto |
| 21:46 | <othermaciej> | so it is also a spec bug |
| 21:46 | <wycats> | othermaciej: is the issue you referred to earlier about behind the firewall the same issue with JSONRequest? |
| 21:46 | <othermaciej> | (or really conscious spec design limitation) |
| 21:46 | <wycats> | one option of course would be to try to calculate it yourself |
| 21:46 | <othermaciej> | wycats: there is some of that issue with JSONRequest, though JS content can to some extent be read cross-site already since there is no same-origin limit on embedding scripts via <script> |
| 21:46 | <wycats> | might work in many cases |
| 21:47 | <othermaciej> | yes, you could get the actual height, and animate from that to 0 |
| 21:47 | <wycats> | othermaciej: right but you can't actually SEE the data with the exception of the __defineSetter__ hole |
| 21:47 | <othermaciej> | going the other way might be trickier (may need an extra layout) |
| 21:48 | <othermaciej> | wycats: there have been other holes (mostly closed now I think) |
| 21:48 | <othermaciej> | but I do think JSONRequest is not a great security design |
| 21:49 | <wycats> | othermaciej: agree 100% |
| 21:49 | <wycats> | I'm just frustrated by having to get people to agree to open up CORS |
| 21:49 | <wycats> | thinking about adding an easy way to do it to Rails |
| 21:49 | <othermaciej> | wycats: are you having trouble persuading people? |
| 21:49 | <wycats> | class MyController; cors_friendly; end |
| 21:49 | <othermaciej> | it would be nice for frameworks to give an easy way to do it |
| 21:49 | <wycats> | othermaciej: there are two issues: (1) the security implications are not obvious, so people want to research; (2) it's never a high priority |
| 21:50 | <othermaciej> | you may want to give the option of allowing access to anyone or to a whitelist, and whether to allow credentials or not |
| 21:50 | <wycats> | othermaciej: I work with the 37 signals guys and they say "cool" to adding CORS to their Campfire API but it's not on their list |
| 21:50 | <zcorpan> | working around the height:auto limitation with script gets really ugly |
| 21:50 | <wycats> | othermaciej: yeah |
| 21:50 | <wycats> | othermaciej: Rails tends to go with 90% case first and then refine to other cases |
| 21:50 | <wycats> | instead of trying to preplan everything... but some additional config wouldn't be bad |
| 21:50 | <othermaciej> | so you're thinking the 90% case is fully public data source that takes no credentials and is open to everyone? |
| 21:52 | <wycats> | othermaciej: the 90% case I think takes credentials via an API token |
| 21:52 | <wycats> | or basic auth |
| 21:52 | <wycats> | more likely an API token |
| 21:52 | <othermaciej> | depends on what kind of credentials you have in mind |
| 21:52 | <othermaciej> | if it's a resource that is somehow per-user, people may want to use cookies |
| 21:53 | <wycats> | othermaciej: that's not a common case |
| 21:53 | <wycats> | the common case is you have an API that is available from Ruby or Java or something |
| 21:53 | <wycats> | via HTTP |
| 21:53 | <wycats> | and you want to open it up for web access |
| 21:53 | <othermaciej> | if for example GMail wanted to offer a contacts service as a data API |
| 21:53 | <wycats> | othermaciej: I'd consider that the 10% case |
| 21:53 | <wycats> | Gmail has smart engineers |
| 21:53 | <othermaciej> | or flickr wanted a photostream data API |
| 21:53 | <wycats> | and we can converge on that case if it gets common |
| 21:54 | <wycats> | othermaciej: why wouldn't an API token work for that case? |
| 21:54 | <othermaciej> | wycats: how does an API token tell you which flickr user is logged into the browser? |
| 21:54 | <othermaciej> | is the token per-user or is it an "app key"? |
| 21:55 | <othermaciej> | if it's per-app, then if you ship it down to the client anyone can rip it from your client-side code |
| 21:55 | <othermaciej> | if it's per user, then you need a server-to-server communication to do setup per-user |
| 21:55 | <wycats> | othermaciej: nah it'd be stored in local storage |
| 21:55 | <wycats> | the user would type in their un/pw, and a call would be made to get the token |
| 21:55 | <othermaciej> | a call to who? |
| 21:55 | <wycats> | a fully open CORS service |
| 21:56 | <othermaciej> | you sure don't want the user typing their site A password into site B |
| 21:56 | <wycats> | ha |
| 21:56 | <wycats> | see: the internet :P |
| 21:56 | <othermaciej> | the whole point of CORS is to avoid brokenness like that |
| 21:56 | <wycats> | but yeah |
| 21:56 | <wycats> | othermaciej: seems basic auth would work |
| 21:57 | <wycats> | othermaciej: I was being snarky -- I of course realize that's bad |
| 21:57 | <othermaciej> | basic auth over CORS requires the same level of opt-in as cookies, so you may as well use cookies since that is probably what the service already uses for normal login |
| 21:57 | <wycats> | othermaciej: hmmm |
| 21:58 | <wycats> | so why wouldn't the default just be "allow cookies"? |
| 21:58 | <wycats> | in the non-preflight case we don't even need to do anything |
| 21:58 | <othermaciej> | well it's pretty easy for a server to opt into cookies |
| 21:58 | <wycats> | in the preflight case it seems "yes" is the right default |
| 21:58 | <wycats> | othermaciej: yeah I've read the spec |
| 21:58 | <othermaciej> | all it has to do is add Access-Control-Allow-Cookies: true |
| 21:58 | <wycats> | othermaciej: I know |
| 21:59 | <wycats> | othermaciej: it seems the make_cors_friendly should do that by default |
| 21:59 | <wycats> | othermaciej: I understand how the spec works, I'm thinking through the 90% case here |
| 21:59 | <othermaciej> | seems fine for a framework to make it the default if that is well-documented and well-understood |
| 21:59 | <wycats> | (you are being very helpful, thank you) |
| 21:59 | <wycats> | othermaciej: make_cors_friendly :cookies => false |
| 21:59 | <wycats> | would be the opt-out |
| 22:00 | <wycats> | obviously that would not be the method name |
| 22:00 | <wycats> | :p |
| 22:00 | <wycats> | probably something more like allow_cross_origin_requests |
| 22:00 | <wycats> | othermaciej: and could be implemented as Rack middleware, although you'd probably want finer control than that offered |
| 22:05 | <wycats> | othermaciej: what is the one-sentence answer to "I need to explore the security considerations" |
| 22:06 | <othermaciej> | wycats: I don't know if there is one - depends on the context |
| 22:07 | <othermaciej> | wycats: if it's a fully public data service that's not per-user and would work without cookies, you could say "other sites can already do this by routing requests bak through their own servers" |
| 22:07 | <othermaciej> | *back |
| 22:09 | <wycats> | lemme look at how conceptually campfire works |
| 22:09 | <wycats> | othermaciej: why is it considered verboten to type un/pw into "some random web app" but not in "some random native iphone app"? |
| 22:09 | <wycats> | expectation discrepancy? |
| 22:13 | <wycats> | "When you're using the API, it's always through an existing user in Campfire. There's no special API user. So when you use the API as "david", you get to see and work with what "david" is allowed to. Authenticating is done with an authentication token, which you'll find on the "Edit my Campfire account" screen in Campfire (click the "Reveal authentication token for API" link). |
| 22:13 | <wycats> | When using the authentication token, you don't need a separate password. But since Campfire uses HTTP Basic Authentication, and lots of implementations assume that you want to have a password, it's often easier just to pass in a dummy password, like X." |
| 22:13 | <wycats> | I think this is pretty representative |
| 22:32 | <til> | i'm serializing some objects to XML, and trying to decide how to serialize the booleans |
| 22:32 | <TabAtkins> | zcorpan: Are you going to ping www-style about the "animating to auto" thing? |
| 22:32 | <TabAtkins> | til: true/false? |
| 22:32 | <til> | i know that you guys consider a boolean to be true if the key is included and false if its omitted |
| 22:32 | <til> | is this a feature of xml, or a quirk of html? |
| 22:33 | <TabAtkins> | Ah, that. That's how HTML works. A general XML language can define booleans however they want. |
| 22:33 | <til> | TabAtkins: i'm wondering whether to represent @mirror as <… mirror = 'true' /> |
| 22:33 | <til> | TabAtkins: i thought so |
| 22:33 | <til> | thanks |
| 22:43 | <zcorpan> | TabAtkins: not tonight |
| 22:43 | <TabAtkins> | Eventually, or you want me to do it? |
| 22:44 | <zcorpan> | you can do it if you want |
| 22:58 | <jwm> | anyone know of some cool examples of a unified object namespace heh |
| 23:04 | <jwm> | not unified heh |
| 23:18 | zcorpan | now has a non-animated js-impl of <details> |
| 23:22 | <zcorpan> | wonder if i should store the open state across reloads and navigation |
| 23:22 | <TabAtkins> | Do you expect that browsers will do so? |
| 23:23 | Hixie | looks at the fullscreen feedback and tries to find if any browsers have actually implemented something he can test |
| 23:23 | <zcorpan> | dunno |
| 23:23 | <zcorpan> | browsers store state of form input |
| 23:23 | <TabAtkins> | Not across navigations, at least. |
| 23:23 | <TabAtkins> | reloads, yes. |
| 23:24 | <zcorpan> | my browser stores form input when going back and forward |
| 23:25 | <TabAtkins> | Ah, true for that. I thought you were referring to, say, a <details> appearing in the same place on a page, and it staying open when you navigated. |
| 23:26 | <TabAtkins> | Easy to save, anyway. Just pop a hidden checkbox into there, and check/uncheck it as appropriate. |
| 23:28 | <TabAtkins> | Are you display:none'ing the contents of the <details>? |
| 23:28 | <zcorpan> | hmm a checkbox might be a reasonable way to implement details for legacy browsers anyway |
| 23:28 | <zcorpan> | yes |
| 23:29 | <TabAtkins> | For accessibility reasons, you may want to position:absolute;left:-9001px; it. |
| 23:29 | <zcorpan> | right now i set tabIndex = 0 on summary and listen to click events on document |
| 23:30 | <zcorpan> | dunno if all browsers fire click for unknown elements when activated with keyboard yet |
| 23:34 | <zcorpan> | as it happens i managed to use <details> with tinymce by using the <blockquote> feature and replacing it with <details> afterwards |
| 23:35 | <TabAtkins> | Hrm. Well, ff doesn't seem to be dispatching keyboard-based clicks on summary, based on a quick test I threw together. |
| 23:35 | <zcorpan> | oh well |
| 23:36 | <zcorpan> | what's the boilerplate for listening to 'enter'? |
| 23:37 | <TabAtkins> | Look for keycode 13, I believe. |
| 23:39 | <TabAtkins> | All right, according to ppk, function(e) { var evt = e||window.event; evt.keyCode==13; } |
| 23:39 | <TabAtkins> | Sub in the rest of your code as appropriate. |
| 23:40 | <TabAtkins> | Use keydown, though, as apparently IE won't fire keypress. |
| 23:42 | <zcorpan> | i was going to use the same function as my onclick handler, but that checks e.which and it seems some browsers use e.which for keyup also |
| 23:43 | <zcorpan> | maybe i can check for keyCode first |
| 23:49 | <TabAtkins> | Just check e.keyCode || e.charCode || e.which |
