| 00:38 | Hixie | considers whether to not bother supporting the multipage apps like flickr and bugzilla in the offline cache mode |
| 00:39 | <Hixie> | or rather, not support having a fallback page if you follow a link to a page that isn't cached yet |
| 02:06 | <kingryan> | Hixie: you around? |
| 02:50 | <Hixie> | kingryan: yo |
| 02:50 | <kingryan> | i have parsing question,if you have a minute |
| 02:51 | <kingryan> | so, i'm under the impression that a <title> found in a <body> should get moved to the <head>, is that right? |
| 02:52 | Hixie | checks |
| 02:53 | <Hixie> | doesn't seem that way, no |
| 02:53 | <Hixie> | what makes you think that? |
| 02:53 | <kingryan> | some test cases in html5lib |
| 02:53 | <kingryan> | and vague memories of hearing that before |
| 02:53 | <Hixie> | i recommend basing your understanding of the spec on the spec itself |
| 02:53 | <kingryan> | of course |
| 02:54 | <kingryan> | but I sometimes i have trouble understanding and following the spec, so its useful to look at other sources |
| 02:55 | <WulfTheSaxon> | Heh. Reminds me of how 90% of questions my channel ( #webdev ) on DALnet can be resolved with a single link the HTML or CSS specs :P |
| 02:56 | <Hixie> | kingryan: if you have trouble with any part of the spec, let us know so i can make it clearer :-) |
| 02:56 | <kingryan> | sure |
| 02:56 | WulfTheSaxon | reads what he just wrote, notices there are entire words missing, and decides to go grab a coffee >.> |
| 02:57 | <Hixie> | hm, i should go grab dinner |
| 03:50 | <MikeSmith> | wow -- no opportunistic caching in offline-apps any more |
| 03:50 | <MikeSmith> | is that because nobody implemented opportunistic caching, or because it wasn't a good idea? |
| 03:54 | <olliej> | MikeSmith: hixie knows all |
| 03:55 | <MikeSmith> | olliej: yeah, was just wondering if there might have been discussion here before I rejoined this morning |
| 03:56 | <olliej> | MikeSmith: yeah, i just looked through the scrollback and couldn't immediately see anything |
| 03:56 | <MikeSmith> | OK |
| 03:56 | <olliej> | MikeSmith: except a brief comment by Hixie on multipage apps like flickr |
| 03:56 | <MikeSmith> | ah |
| 03:57 | <olliej> | MikeSmith: but i'm not sure if it was relevant to this |
| 03:58 | <olliej> | MikeSmith: i only really follow the canvas stuff |
| 03:58 | <MikeSmith> | well, I know you guys hadn't implemented opportunistic caching and Mozilla hadn't either, so I'd reckon that probably had some influence over the decision about it |
| 03:58 | <olliej> | not necessarily |
| 03:59 | <MikeSmith> | olliej: about canvas, is that because you're responsible for canvas code in Webkit? |
| 03:59 | <olliej> | MikeSmith: generally things only seem to be pulled when multiple engines say "no" |
| 03:59 | <olliej> | MikeSmith: yup |
| 03:59 | <MikeSmith> | yeah |
| 03:59 | <MikeSmith> | did you do the original implementation? |
| 03:59 | <olliej> | MikeSmith: no |
| 04:00 | <olliej> | MikeSmith: if i had there would have been a distinct Path object |
| 04:00 | <MikeSmith> | heh |
| 04:00 | <olliej> | MikeSmith: that was not attached to the context |
| 04:00 | <olliej> | stab stab stab |
| 04:00 | <olliej> | ;D |
| 04:00 | <MikeSmith> | :) |
| 04:00 | <olliej> | canvas path behaviour is hideous it's the result of a poor design in the original implementation that was then misinterpreted by mozilla |
| 04:01 | <olliej> | leading to the current excitement wherein a Path retains its visible screen location across context save/restore points |
| 04:01 | <olliej> | yo othermaciej |
| 04:01 | <othermaciej> | hi olliej |
| 04:02 | <Hixie> | MikeSmith: i will be sending a long mail about caching stuff |
| 04:02 | <MikeSmith> | Hixie: Ok |
| 04:05 | <MikeSmith> | olliej: I suppose there's general agreement that the way canvas ended up being standardized is not the ideal way, and would be nice to not have been stuck with some of what it ended up with. But I guess some might say the end result is not much worse that other things -- parts of the DOM, whatever -- that we're also stuck with now |
| 04:06 | <olliej> | MikeSmith: alas it came into existence (afaict) prior to the "standardisation" of vendor prefixes, etc |
| 04:25 | <roc> | we have implemented opportunistic caching on trunk |
| 04:57 | <MikeSmith> | roc: was that a pretty recent change? last I had heard (a couple months back, I guess), you hadn't yet |
| 04:58 | <roc> | Sep 30 |
| 04:59 | <roc> | https://bugzilla.mozilla.org/show_bug.cgi?id=442813 |
| 05:00 | roc | mumbles something about fast-paced development |
| 07:52 | <annevk3> | http://www.mnot.net/blog/2008/10/16/site-meta |
| 07:57 | <annevk3> | othermaciej, you around? should I e-mail es-discuss about ByteArray instead? |
| 07:57 | <othermaciej> | annevk3: I'm around |
| 07:57 | <othermaciej> | annevk3: I can probably do it later tonight or tomorrow, but you should feel free to do it instead if you want |
| 07:58 | <annevk3> | k, I think I'll just do it and then you can jump in :) |
| 08:07 | <othermaciej> | ok |
| 08:57 | <hsivonen> | hmm. kingryan is here only when I am asleep |
| 09:28 | <hsivonen> | is it intentional that the issues graph no longer reacts to hover? |
| 09:49 | <hsivonen> | Would you say this is an accurate statement: "The HTML5 work on the other hand uses a centralized extensibility mechanism based on formalized tagsoup parsing." |
| 09:50 | <Hixie> | not really |
| 09:50 | <Hixie> | and yes, i removed the hover effect |
| 09:51 | <hsivonen> | Hixie: how would you fix the statement? |
| 09:51 | <hsivonen> | ok. (re: hover) |
| 09:51 | <hsivonen> | (I prefer the term "text/html" over "tagsoup".) |
| 09:52 | <Hixie> | "The HTML5 language has a variety of extension mechanisms." for the first part; I've no idea what the second part is trying to say |
| 09:53 | <hsivonen> | do we have a wiki page enumerating all the extension mechanisms? meta[name], [rel], [class], data-* off the top of my head |
| 09:53 | <Hixie> | the faq lists them iirc |
| 09:54 | <hsivonen> | so it does |
| 09:56 | <hsivonen> | as far as I can tell, the sentence is trying to make the point that a random group can't add a feature like SVG or MathML to text/html unilaterally |
| 09:57 | <Hixie> | yeah |
| 09:57 | <Hixie> | well |
| 09:57 | <Hixie> | that's mostly up the browser vendors |
| 09:57 | <Hixie> | i mean, you can't add any feature to the web platform cross-browser unilaterally |
| 09:57 | <hsivonen> | in XML, they can syntactically, but they still need the buy-in of people who can commit code to Gecko, WebKit, Trident and Presto in order to get their stuff in the hands of users |
| 09:58 | <othermaciej> | I think people sometimes think making their own tags that browsers don't do anything special with is somehow really useful and important |
| 09:58 | <othermaciej> | and other people just don't understand how browsers work and imagine defining their own extension with rendering and behavior and such will magically work |
| 09:58 | <Hixie> | the whatwg "unilaterally" (i.e. without w3c approval) invented a whole bunch of new tags |
| 09:58 | <Hixie> | so clearly it is possible even in text/html |
| 09:59 | <othermaciej> | in WebKit we invented some new tags and attributes |
| 09:59 | <Hixie> | similarly, microsoft invented <marquee>, apple invented <canvas>, netscape invented <blink> and <keygen>, etc |
| 10:00 | <Hixie> | in general, the web platform is better off without unilateral browser-implemented extensions, though |
| 10:00 | <othermaciej> | I think people want to be able to invent tags and have a validator call it correct |
| 10:00 | <hsivonen> | which reminds me that keygen is still missing from the spec |
| 10:00 | <othermaciej> | keygen is such a ridiculous feature |
| 10:00 | <hsivonen> | surely it has to be "specified" somewhere in the bowels of mxr.mozilla.org |
| 10:00 | <Hixie> | keygen feedback is pending |
| 10:00 | <Hixie> | along with all of wf2 feedback |
| 10:01 | <Hixie> | i think othermaciej is right, people want to be able to be told that making up their own thing is ok |
| 10:01 | <Hixie> | but it's not clear why their desire is valid |
| 10:01 | <Hixie> | (for lack of a better term) |
| 10:01 | <hsivonen> | othermaciej: it's really simple to make a validator that calls stuff correct... function isInputValid(input) { return true; } |
| 10:02 | <othermaciej> | hsivonen: yes, but it should still tell the bad people who don't use double quotes or make syntax errors or invent tags in an unapproved way that they are bad |
| 10:02 | Hixie | wonders what hsivonen is responding to |
| 10:02 | <gsnedders> | Hixie: Can we not have a similar vendor prefix thing to CSS? |
| 10:02 | <othermaciej> | hsivonen: otherwise, the good people who make unilateral extensions in the Official Approved way cannot feel better than other people |
| 10:03 | <Hixie> | gsnedders: doesn't really work for elements. for attributes we somewhat could, though it doesn't really work very well there either. |
| 10:03 | <gsnedders> | Hixie: Doesn't work why? |
| 10:03 | <Hixie> | gsnedders: html has different characteristics than css |
| 10:03 | <othermaciej> | for attributes it might be plausible |
| 10:03 | <gsnedders> | Hixie: I think I might have just noticed :) |
| 10:03 | <othermaciej> | for elements I don't think it works |
| 10:03 | <gsnedders> | Lack of fallback, etc.? |
| 10:03 | <othermaciej> | for attributes it is a pain since desire to dynamically change attribute values is likely to be much higher |
| 10:03 | <Hixie> | gsnedders: e.g. even in css it doesn't make sense for some things; e.g. you couldn't really make up an alternative to 'display' and call it '-foo-display', because then you'd have unclear precedence models, etc |
| 10:03 | <gsnedders> | Anything else will still notice iit? |
| 10:03 | <othermaciej> | also vendor prefix doesn't work very well for scripting interfaces |
| 10:04 | <hsivonen> | Hixie: I find it interesting that often people tend to care more about validator passing their stuff than about validator informing them about their mistakes |
| 10:04 | <Hixie> | othermaciej: it works ok for scripting stuff |
| 10:04 | <hsivonen> | Hixie: I think othermaciej's observation is correct, though |
| 10:04 | <Hixie> | hsivonen: i think it's actually a very small group of people to be honest |
| 10:04 | <othermaciej> | Hixie: well, it's not completely untenable, just painful; I guess you could check for every vendor prefixed version as prologue and rename them to a common name |
| 10:04 | <Hixie> | hsivonen: relative to the total html authoring population |
| 10:05 | <gsnedders> | hsivonen: That entire group is minute though |
| 10:05 | <gsnedders> | Ooo… nice weather when I get to Cannes! |
| 10:05 | <othermaciej> | Hixie: but that doesn't really work for IDL attributes (i.e. JS properties) as opposed to methods |
| 10:05 | <Hixie> | othermaciej: typically since the features will be different in each implementation, you'd do something like if (window.fooBar) { } else if (window.bazBar) { } else { } |
| 10:05 | <othermaciej> | Hixie: see, even you can't code it right |
| 10:05 | <Hixie> | othermaciej: e.g. attachEvent vs addEventListener |
| 10:05 | <othermaciej> | what you wrote fails if fooBar happens to have a false value |
| 10:06 | <Hixie> | well i'm assuming it's a function in this case |
| 10:06 | <Hixie> | but sure, it depends on what you're doing |
| 10:06 | <othermaciej> | for functions it is easier since you can make a common wrapper or copy to a common name |
| 10:06 | <Hixie> | depends on the function |
| 10:06 | <othermaciej> | for attributes (in the IDL sense) it doesn't really work |
| 10:06 | <Hixie> | but sure |
| 10:07 | <othermaciej> | I mean, it doesn't fail quite as hard as vendor prefix on elements but it is IMO pretty bad |
| 10:08 | <Hixie> | well it's a bit worse than css, sure |
| 10:08 | <Hixie> | it's not like it's that awesome in css either |
| 10:08 | <othermaciej> | well, you don't need control structures to repeat yourself without breakage in CSS |
| 10:08 | <hsivonen> | "Adobe will allow over-the-air updates of the Flash player. Providers and carriers can push out new player versions to their users." Huh? Has Adobe previously forbidden updates?? |
| 10:09 | <othermaciej> | (and fairly obscure ones to be correct) |
| 10:09 | <Hixie> | at the end of the day, it's better for vendor-specific extensions to be prefixed wherever they are, but it's even better for the vendor-specific extensions to be discussed before shipping in public so that a multilateral agreement can be formed first |
| 10:09 | <othermaciej> | the normal pre-iPhone model for mobile phone software is that you essentially never update it |
| 10:10 | <othermaciej> | in theory you can for some "smartphones" when tethered but afaict hardly anyone does |
| 10:10 | <othermaciej> | we have done some prefixing and try to form agreement when we can |
| 10:11 | <othermaciej> | but I do think that multiple prefixed versions of a method or attribute would be a greater lose than multiple prefixed versions of a CSS property |
| 10:11 | <othermaciej> | fortunately, coordination around HTML and around miscellaneous APIs seems easier than for new CSS stuff |
| 10:11 | <MikeSmith> | othermaciej: "the normal pre-iPhone model for mobile phone software is that you essentially never update it" is patently untrue at least as far as Japan is concerned |
| 10:11 | <othermaciej> | MikeSmith: it's certainly true in the US - I am not really familiar with Japan |
| 10:12 | <MikeSmith> | the US is the last place in the world to be looking at for precedents around mobile data services |
| 10:12 | <othermaciej> | my impression is that the major handset vendors in Europe don't exactly push updates too widely either - for many phones the only way to update the firmware would be at the carrier's brick and mortar store |
| 10:13 | <othermaciej> | I don't know of any phone that will update system software over the air |
| 10:13 | <MikeSmith> | also as far as mobile software in Japan, the App Store is also not particularly novel in any way |
| 10:13 | <MikeSmith> | othermaciej: I do |
| 10:13 | <othermaciej> | MikeSmith: seriously? |
| 10:13 | <othermaciej> | because that is kind of terrifying even to me |
| 10:14 | <othermaciej> | MikeSmith: anyway I am sure Japan is cool and technologically superior and everything but I think most US-based companies still have a US-centric point of view |
| 10:17 | <MikeSmith> | othermaciej: I don't think Japan is all that technologically superior as far as mobile technologies go. it's just that we have more real use cases for the technology here and a thriving market. |
| 10:18 | <othermaciej> | apparently over-the-air mobile firmware updates are not all that uncommon now (as far as I can tell from googling), so I guess my impression of how things work was slightly out of date |
| 10:19 | <zcorpan> | "User agents that cannot render the video may instead make the element represent a link to an external video playback utility or to the video data itself." -- this makes me wonder if someone's working on a text-based browser that follows the html5 spec |
| 10:19 | <hendry> | MikeSmith: what mobiles update? I thought the Japanese market pushed new series phones every 6 months 8x 9x with new APIs |
| 10:19 | <othermaciej> | MikeSmith: I have heard many times that Japan (and Europe) have broader deployment than the US of relatively high-bandwidth wireless service and higher market penetration of "smartphones" relative to "feature phones" |
| 10:19 | <MikeSmith> | we basically don7t have anything but smartphones and features phones in Japan |
| 10:19 | <MikeSmith> | there is nothing else |
| 10:20 | <hsivonen> | what's a "feature phone"? |
| 10:20 | <hendry> | hsivonen: what's a mobile? :) |
| 10:20 | <othermaciej> | my impression is that Japan has various kinds of interesting software innovation going on but as far as I can tell, most of it doesn't really make it out of Japan other than console games and Ruby |
| 10:20 | <othermaciej> | a "feature phone" is what is currently a low-end phone |
| 10:21 | <othermaciej> | the category below "smartphone" |
| 10:21 | <MikeSmith> | oh |
| 10:21 | <othermaciej> | they are called that because (as I just learned recently) they used to be high end |
| 10:21 | <hsivonen> | othermaciej: ok. New term to me. |
| 10:21 | <othermaciej> | they tend to have things like a camera, a primitive browser, etc |
| 10:21 | <MikeSmith> | well, I take back what I said then -- we don't have "feature phones" -- we have only one class of handset |
| 10:22 | <othermaciej> | but not, typically, fancy installable software, a large screen, major league internet capabilites, etc |
| 10:22 | <hendry> | MikeSmith: what's a popular Web site for Japanese mobile users? |
| 10:22 | <othermaciej> | apparently they used to be the high end relative to phones that just made calls and that's it |
| 10:23 | <MikeSmith> | hsivonen: new handsets for KDDI/Au and DoCoMo and Softbank Mobile get released here every 3 months -- and no, they do not deploy new APIs every time the release new devices. The APIs are quite stable. |
| 10:24 | <hendry> | i was under the impression they launch new APIs and new services and hence drive sales that way |
| 10:24 | <othermaciej> | even though I am biased, I will say anyway that regardless how innovative it is or not, I find the App Store really impressive |
| 10:24 | <MikeSmith> | hendry: mobile version the Mixi social-networking service, mobile versions of restaurant-information sites, mobile versions of map sites that rely on location-awareness in browsers and markup extensions that expose location information to Web apps, ... |
| 10:24 | <othermaciej> | because normally I hate everything about obtaining new software |
| 10:24 | <othermaciej> | but not with the App Store |
| 10:24 | <MikeSmith> | hendry: they do, but not at the kind of rate |
| 10:24 | <othermaciej> | I want an App Store for the Mac now |
| 10:25 | <hendry> | MikeSmith: there is even a series number across sharp, nec phones if i remember correctly that correspond the api/service generation |
| 10:27 | <Hixie> | othermaciej: four major features missing on the app store that kill it for me: it's not an open market place, it doesn't support open source software, i can't filter by price, and i can't try before paying. |
| 10:28 | <othermaciej> | Hixie: I would like to try before I buy, though with the free apps it is not a problem, and with commercial apps that's not the norm in any case |
| 10:29 | <Hixie> | with commercial apps one can find the app on bittorrent and try it before buying |
| 10:29 | <hsivonen> | othermaciej: I can try the apps from Omni, etc. before I buy. Even iWork from Apple. |
| 10:29 | <Hixie> | (not that i've actually used a "commercial" app that didn't have a demo or that i hadn't tried in some other legitimate way in years) |
| 10:29 | <othermaciej> | I have heard the App Store terms make it impossible to publish open source software, but I am not sure what aspect of the terms makes that impossible |
| 10:30 | <MikeSmith> | hendry: there are consistent series numbers or prefixes across all devices that are deployed for a particular carrier's service |
| 10:30 | <othermaciej> | some iPhone apps do have both free and pay versions (often with ads in the free version though) |
| 10:30 | <MikeSmith> | e.g., for DoCoMo, current series is "906" |
| 10:30 | <Hixie> | othermaciej: LGPL requires that the redistributor allow the user to link with another library. There's no way to do that on the iPhone platform. |
| 10:30 | <othermaciej> | personally I decide what software to get by word of mouth, if it costs money |
| 10:31 | <othermaciej> | Hixie: I would think posting the full source of your app in an alternate online location would be sufficient |
| 10:31 | <Hixie> | (which e.g. means that certain parts of safari can't ship on the iphone, but don't tell your lawyers) |
| 10:31 | <MikeSmith> | hendry: previous one was 706 |
| 10:31 | <BenMillard> | othermaciej, my mum and dad's phone can be updated by installing the vendor's update software onto your PC, using that to download the phone's updates to your PC, then transferring the updates to your phone, then rebooting the phone |
| 10:31 | <BenMillard> | *phones |
| 10:31 | <Hixie> | othermaciej: no, because i can't recompile the app and put it on the device. at least, that's the problem as i understand it. |
| 10:32 | <othermaciej> | Hixie: I don't believe the LGPL requires the developer to provide the user with the relevant dev tools |
| 10:32 | <MikeSmith> | Hixie: at Au, it's 60 series, 50 series before that, etc. |
| 10:32 | <othermaciej> | Hixie: otherwise, how could open source GUI software for Windows exist (since afaik only proprietary compilers can build such)? |
| 10:33 | <Hixie> | there are a number of free software compilers for windows. |
| 10:33 | <Hixie> | but the problem is that given the iphone platform, one can't change the software. |
| 10:33 | <Hixie> | since it is a closed platform. |
| 10:34 | <othermaciej> | the only free software compilers I know of for Windows can only build command-line tools |
| 10:34 | <othermaciej> | I don't think the LGPL has any requirements about enabling you to run the software on any particular platform once you change and build it |
| 10:35 | <othermaciej> | I think the problem before was that the NDA made it effectively illegal to distribute the source of anything that used iPhone OS APIs |
| 10:35 | <othermaciej> | because that would ispo facto violate the NDA on said APIs |
| 10:35 | <othermaciej> | I believe that problem is now solved |
| 10:36 | <othermaciej> | I will say for the record that I would much prefer if the iPhone let me put any software I want without having to be approved as a developer by Apple and paying them extra money for the privilege |
| 10:36 | <othermaciej> | so I am not going to defend the policy |
| 10:36 | <Hixie> | "For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies |
| 10:37 | <Hixie> | i don't believe that the $79 i have to pay apple to run code on the iphone can be said to be "normally distributed with the major components of the operating system on which the executable runs" |
| 10:37 | <othermaciej> | well under that interpretation Safari for Windows and Chrome are equally in violation |
| 10:37 | <Hixie> | like i said |
| 10:37 | <othermaciej> | since they require Visual Studio to build |
| 10:38 | <Hixie> | anyway |
| 10:38 | <othermaciej> | indeed Mac OS X does not come with dev tools, you need a separate DVD |
| 10:38 | <Hixie> | i'll let the lawyers worry about this one |
| 10:38 | <othermaciej> | (which you can download or get for free, but ok) |
| 10:39 | <Hixie> | at the end of the day, the practical problems with the iphone and the app store being locked down are real problems for me regardless of whether the issue is technically legally ok or not |
| 10:39 | <othermaciej> | I think the fact that "compiler" counts as a "major component of the OS" means it is ok to rely on anything distribtued with the compiler, even if the compiler and the kernel areobtained separately |
| 10:39 | <Hixie> | the compiler for the iphone is separate from the $79 i have to pay to actually get code onto my device |
| 10:40 | <othermaciej> | "reproducing the executable" is also separate from getting it onto your device |
| 10:41 | <Hixie> | well like i said, at the end of the day, the practical problems with the iphone and the app store being locked down are real problems for me regardless of whether the issue is technically legally ok or not |
| 10:41 | <othermaciej> | I agree in principle that it is bogus that you have to pay extra to get code on the device, whether it is open source or not though |
| 10:42 | <othermaciej> | in practice, I like my iPhone more since the App Store came out than before |
| 10:42 | <othermaciej> | I could imagine liking it even more |
| 10:43 | <othermaciej> | I continue to feel that the process of obtaining sofware for my iPhone feels more convenient than getting software for my Mac, even though the process in other ways is restricted in ways I think are wrong |
| 10:43 | <Hixie> | i agree that the actual process of getting software on the iphone is nice |
| 10:43 | <Hixie> | it's quite similar to the process of getting software on a linux distro |
| 10:43 | <Hixie> | though with a nicer ui, to be sure |
| 10:43 | <roc> | for the record, free compilers for Windows are quite capable; you can build Firefox with mingw-gcc |
| 10:44 | <othermaciej> | I can only hope that Apple continues to reduce the restrictions on the iPhone over time, and in the meantime I will continue to contribute to the one fully open platform that the iPhone supports |
| 10:44 | <othermaciej> | roc: I have heard from multiple sources that mingw can't generate code that can successfully link to windows system DLLs |
| 10:45 | <othermaciej> | maybe that is wrong |
| 10:45 | <othermaciej> | or maybe it is limited to C++ or COM interfaces |
| 10:46 | <othermaciej> | or maybe it is not really a problem |
| 10:46 | <roc> | http://gemal.dk/mozilla/build.html |
| 10:47 | <hsivonen> | Hixie: IANAL, but I believe the canonical interpretation of "kernel" and "compiler" in GPLv2 series is that you don't need to distribute the compiler--even if it's non-Free |
| 10:47 | gsnedders | votes MIT license ftw |
| 10:49 | <hsivonen> | Hixie: I think the status of the portability layer under Apple's WebKit is a more interesting case than the compiler |
| 10:49 | <othermaciej> | roc: interesting |
| 10:50 | <othermaciej> | hsivonen: you mean the proprietary libraries that the Apple Windows port of WebKit link to as DLLs? |
| 10:51 | <hsivonen> | othermaciej: those and the thin layer on Mac if it's still there |
| 10:51 | <othermaciej> | I do not believe that dynamically linking to anything can be an LGPL violation regardless of license terms |
| 10:51 | <roc> | as for LGPL2, all you're required to do in section 6 is ensure that the user can relink your executable against their own version of the LGPL'ed library. |
| 10:51 | <othermaciej> | the Mac non-open-source .a is linked by a purely BSD-licensed dylib |
| 10:52 | <othermaciej> | (it is also shrinking) |
| 10:52 | <roc> | AFAIK you're not required to make sure that that executable can be run on a specific device, so signing and/or other restrictions do not violate LGPL2 |
| 10:52 | <roc> | which is one reason why GPL3 (and LGPL3) were created |
| 10:52 | <roc> | (which are anathema to Apple) |
| 10:54 | <hsivonen> | I wonder if Apple is going to implement a C++ compiler, too, in addition to clang |
| 10:55 | <roc> | clang is intended to be a C++ compiler eventually |
| 10:55 | <gsnedders> | hsivonen: I think the aim is for clang to be C++ too |
| 10:55 | <hsivonen> | ok |
| 10:55 | <othermaciej> | having looked a fair bit at LLVM internals, I expect it to become a genuinely better compiler than GCC |
| 10:55 | <othermaciej> | but anything could happen |
| 10:56 | <gsnedders> | othermaciej: Is there any reason why LLVM wasn't used for SF? |
| 10:57 | <othermaciej> | gsnedders: we think the way we did it is a good approach |
| 10:57 | <othermaciej> | I can give you a slightly less vague answer on #squirrelfish where it is less off-topic, if you really care to know |
| 10:58 | <hsivonen> | which reminds me that I should go and learn why stack-based VMs are the common VM design |
| 10:58 | <othermaciej> | probably because most people thought of it as the obvious way to do it back in the day |
| 10:59 | <othermaciej> | I think it is now uncontroversial that register-based is better, to anyone who has studied the topic |
| 10:59 | <othermaciej> | though with a strong JIT it does not matter as much |
| 10:59 | <hsivonen> | I've always had a hard time understanding why it would be the obvious way when CPUs are register-based |
| 10:59 | <othermaciej> | unless your JIT kicks in only part of the time |
| 10:59 | <roc> | stack-based VMs are the common VM design because VM designers are silly |
| 10:59 | <othermaciej> | CPUs having lots of registers is a fairly recent development in the history of VMs |
| 11:00 | <Philip`> | Hooray for Parrot |
| 11:00 | <othermaciej> | and a register-based VM doesn't really work like a register-based CPU anyway; it has infinite virtual registers |
| 11:00 | <Philip`> | (What other register-based VMs exist now?) |
| 11:00 | <Philip`> | Parrot had finite (32) registers for quite a while, and that was still a register-based VM back then |
| 11:01 | <Philip`> | (but then they realised that limit was silly since they could easily make it unbounded) |
| 11:01 | <roc> | this was obvious in 1996 if not earlier. The remarkable thing was the .NET designers didn't learn the lesson |
| 11:03 | <othermaciej> | I don't know why you would make a register VM with finite registers |
| 11:03 | roc | spent a lot of time wrestling with Java (stack based) bytecode over the years |
| 11:03 | <othermaciej> | roc: I am a bit curious why both SpiderMonkey and Tamarin are stack-based |
| 11:03 | <roc> | because Spidermonkey was designed before 1996 :-) |
| 11:03 | <roc> | Tamarin, I dunno |
| 11:04 | <othermaciej> | I will also reveal that the architect of LLVM advised us to go stack-based instead of register-based for SquirrelFish |
| 11:04 | <othermaciej> | (fortunately we didn't listen) |
| 11:04 | <roc> | wow |
| 11:04 | <othermaciej> | roc: so spidermonkey was never really rearchitected from the original JavaScript implementation? |
| 11:05 | <roc> | not from scratch, no |
| 11:05 | <roc> | AFAIK |
| 11:05 | <roc> | I'm no expert |
| 11:06 | <othermaciej> | JavaScript was creaed in 1995 according to wikipedia |
| 11:06 | <othermaciej> | *created |
| 11:06 | <roc> | sounds right |
| 11:08 | <othermaciej> | I think wide, quantified knowledge of the superiority of register machines may be more recent than 1996 |
| 11:09 | <othermaciej> | all the papers I have saved on the topic date to the 2000's |
| 11:10 | <gsnedders> | othermaciej: s/'// plz. :P |
| 11:11 | <othermaciej> | (oddly, v8 even though it has no bytecode and so could be argued not to be a VM, appears to have implicit stack machine semantics in the code it generates) |
| 11:11 | <roc> | well |
| 11:11 | <doublec> | regarding bufferedBytes, totalBytes, etc on the list. For Ogg files, it's easier to get values for those than buffered/duration |
| 11:11 | <doublec> | since duration requires multiple seeks |
| 11:12 | <doublec> | and getting the ranges of the buffered data requires having decoded that data |
| 11:12 | <roc> | OmniVM appeared in 1995, and it was a register VM ... e.g. http://www.w3.org/Conferences/WWW4/Papers/165/ |
| 11:12 | <gsnedders> | I do like how I get on lastweekinhtml5 despite not posting to whatwg since July and public-html since September |
| 11:13 | <gsnedders> | I guess lurking here causing chaos is enough :) |
| 11:13 | <roc> | OK, it was obscure, and I mostly know about it because Steve Lucco joined the CMU faculty the same year I arrived as a grad student, and some of my friends worked on it for him |
| 11:14 | <othermaciej> | I see, it is a virtual RISC architecture |
| 11:14 | <roc> | we thought the uniform ISA was better than Java bytecodes |
| 11:14 | <roc> | registers were part of that uniformity |
| 11:15 | <othermaciej> | I guess there would have been many other hypothetical simulator-only RISC architectures though intended for pedagogy rather than deployment |
| 11:15 | <othermaciej> | indeed I recall using one in college |
| 11:15 | <roc> | it's true that there was no work done to quantify ISA design choices. Steve probably designed it that way because it was easier to target with existing C compilers |
| 11:16 | <othermaciej> | (would have been around 96 or so but I think they'd been using it a while) |
| 11:16 | <roc> | the funny thing is that Microsoft bought his company and either buried the technology, or according to some sources, put some of it in .NET |
| 11:16 | <othermaciej> | wow, I realize now that I once actually vaguely knew something about how a CPU works internally |
| 11:17 | <othermaciej> | enough that I could explain what a "pipeline hazard" was |
| 11:17 | <roc> | too bad the register design didn't make it |
| 11:17 | <othermaciej> | the only excuses I can think of for .NET to be a stack machine would be (a) to copy JVM more thoroughly and (b) if you JIT, it doesn't matter as much |
| 11:19 | <othermaciej> | it is interesting that the existince of JavaScript in the browser has beaten down nearly every add-on execution environment for the Web |
| 11:19 | <othermaciej> | other than Flash |
| 11:19 | <roc> | yeah |
| 11:19 | <BenMillard> | damn, I have a folder at /web/study/2008/tables/ but also want a web page at /web/study/2008/tables :( |
| 11:20 | <roc> | The bibliography for that Omniware paper is a scary flashback to a world of walking-dead wannabe execution environments |
| 11:20 | <othermaciej> | very interesting stuff |
| 11:20 | <othermaciej> | this channel is educational! |
| 11:21 | <gsnedders> | BenMillard: n00b. |
| 11:21 | <gsnedders> | othermaciej: Apart from me, I'm not. |
| 11:22 | <MikeSmith> | This channel is definitely educational. |
| 11:23 | <BenMillard> | othermaciej, our downstairs PC has the Java thing from Sun for a couple of the online word games my mum plays in IE7 |
| 11:23 | <BenMillard> | gsnedders, what would you do? |
| 11:24 | <gsnedders> | BenMillard: index.html? |
| 11:24 | <BenMillard> | gsnedders, hang on I'll give you actual links |
| 11:24 | <Hixie> | othermaciej: re v8 having stack-based semantics... don't all c++ compilers also have stack-based semantics in that sense? or am i mixing up different concepts called "stack" here |
| 11:25 | <othermaciej> | Hixie: you are mixing up two different concepts of "stack" |
| 11:25 | <Hixie> | ah ok |
| 11:25 | <Hixie> | what's the stack in a stack vm used for then? |
| 11:25 | <othermaciej> | C/C++ compilers have a stack but access things that live on the stack by reading an offset from the stack pointer rather than with push/pop semantics, most of the time |
| 11:25 | <roc> | one thing Steve realized, and published in 1997 ( http://portal.acm.org/citation.cfm?id=349307 ), is that general-purpose compressors, plus intelligent stream splitting, applied to a nice regular data format, get much better compression than trying to design a nice "compact" format (which blows away a big chunk of the "rationale" for stack-based bytecodes) |
| 11:25 | <othermaciej> | in a stack VM, you're almost always operating on the top few items on the stack |
| 11:26 | <othermaciej> | it's like forth |
| 11:26 | <othermaciej> | if you know forth at all |
| 11:26 | doublec | is a forth fan |
| 11:26 | <roc> | doublec is evil |
| 11:26 | <doublec> | :-) |
| 11:27 | <othermaciej> | roc: in-memory compactness might still be valuable in some cases, and you would not want to use general-purpose compression there |
| 11:27 | <Hixie> | oh you mean like if you want to add two numbers you push push add and have the result on the stack, as opposed to anything to do with recursion? |
| 11:27 | <othermaciej> | but a register bytecode can be made fairly compact too |
| 11:27 | <othermaciej> | Hixie: yeah, basically |
| 11:28 | <Hixie> | weird that v8 would do things using a stack-like approach |
| 11:28 | <Hixie> | seems counterintuitive |
| 11:28 | <roc> | Hixie: a stack-based add looks like "push 77; push 33; add; print;". Register based add looks more like 'load r0,77; load r1,33; add r2,r0,r1; print r2;" |
| 11:28 | <Hixie> | right |
| 11:28 | <othermaciej> | the SquirrelFish virtual register file is in a sense a stack too, but it's always accessed with random access rather than with push/pop/dup/etc |
| 11:29 | <othermaciej> | but it does push new frames for calls and such |
| 11:29 | <othermaciej> | register generally wins when your local variables are in registers and you operate on vars |
| 11:30 | <roc> | othermaciej: yeah, in-memory compactness might be valuable in some cases, but it's not clear what those cases are :-) |
| 11:30 | <othermaciej> | since instead of loadvar 1; loadvar2; add; print; you can just say add r3, r1, r2; print r3; |
| 11:30 | <BenMillard> | (Off-topic) Apparently this is "by design" for SmartFTP: http://www.smartftp.com/forums/UI-Preferences-Clobbered-by-Upgrade-t15546.html |
| 11:31 | <gsnedders> | BenMillard: Nothing is off-topic. Expecting anything on-topic would be logical. |
| 11:31 | <roc> | if your programs are big, you probably win by caching decompressed instruction blocks. If your programs are small, none of it matters. The sweet spot for tricky "compact" formats is somewhere in between, if indeed it exists at all |
| 11:32 | <roc> | this lesson actually applies to more than just instruction formats. I have seen far too many complex tricky "compact" data formats |
| 11:32 | <othermaciej> | clearly the Android folks did not think any compactness win from a stack VM was worth it |
| 11:32 | <othermaciej> | despite being driven so much by memory constraints |
| 11:32 | <doublec> | i got rickrolled via <video> earlier today. someone sent a link to an ogg file they said was crashing. You can guess what it was. |
| 11:33 | <othermaciej> | yeah designing a data format for compactness is almost certain to be wrong |
| 11:33 | <roc> | well |
| 11:33 | <othermaciej> | (unless it is for truly gargantuan data sets) |
| 11:33 | <gsnedders> | doublec: Don't fix video bugs :) |
| 11:34 | <roc> | another funny thing ... the RISC designers always touted their regular instruction sets as a great thing |
| 11:35 | <roc> | turns out they were wrong, and the bizarre irregular tricky "compact" x86 instruction set actually wins |
| 11:35 | <roc> | because code cache footprint matters and the horrible decode logic, in the end, doesn't matter |
| 11:36 | <othermaciej> | I think x86 might win mainly because of volume and therefore ability to apply extreme engineering resources |
| 11:36 | <othermaciej> | not because anything about the instruction set is good |
| 11:37 | <roc> | oh, absolutely |
| 11:37 | <othermaciej> | though I think the worst thing is not the tricky encoding but rather the paucity of general-purpose registers |
| 11:37 | <roc> | I just mean that the instruction set """design""" in the end turned out to be an advantage, not a disadvantage |
| 11:37 | <othermaciej> | you can just as easily devote more silicon to cache instead of decode logic |
| 11:38 | <othermaciej> | and x86_64 can often be faster just on the back of extra registers despite torturing at least your dcache (dunno enough about it to say as to icache) |
| 11:38 | <roc> | I don't think the silicon devoted to decode logic is comparable to cache |
| 11:39 | <roc> | I remember some architect talking about this. One of the pain points for x86 is decoding multiple instructions per cycle. It's hard when you don't even know where the second instruction *starts* |
| 11:40 | <othermaciej> | heh |
| 11:40 | <roc> | so they just have several decoders, which decode starting at PC, PC+1, PC+2, etc |
| 11:40 | <othermaciej> | so anyway I think ARM goes further towards compactness and yet is quite RISCy |
| 11:40 | <roc> | and they throw away the results that they don't need |
| 11:40 | <othermaciej> | wonder how fast code would go on an ARM CPU that was designed more for speed than power consumption |
| 11:41 | <roc> | oh, and only the first decoder is capable of decoding the "rare" instructions |
| 11:41 | <othermaciej> | but yes, Intel has proven that orthogonality and regularity are way overrated in an instruction set |
| 11:43 | <othermaciej> | ok I know this is even more wildly off-topic but these mccain tongue pictures are freaking me right out |
| 11:43 | <othermaciej> | did he really do that? |
| 11:43 | <othermaciej> | did anyone here watch the us presidential debate? |
| 11:43 | BenMillard | publically acknowledges that gsnedders won the URL problem. |
| 11:43 | gsnedders | has leet mod_rewrite skillz |
| 11:43 | <gsnedders> | but is still beaten by DrBacchus |
| 11:50 | <gsnedders> | (who wrote the book) |
| 12:01 | <Philip`> | "designing a data format for compactness is almost certain to be wrong" - that's something that XML has usefully demonstrated, e.g. it's apparent you can store 3D meshes in ASCII XML files and it won't actually be totally insane, and then you can benefit from the readability and extensibility and whatnot without having to constantly worry about file size |
| 12:02 | <roc> | well |
| 12:02 | <roc> | XML would have demonstrated that, had XML not been poorly designed in other ways |
| 12:04 | <Philip`> | It demonstrates it despite being poorly designed in other ways, because people (who usually care greatly about performance) do use it for that |
| 12:05 | <roc> | in many situations, people who care about performance avoid XML and are right to do so |
| 12:07 | Philip` | is thinking of COLLADA in particular, which it seems real people do really use (and are relatively happy to do so, compared to all the other obscure proprietary binary formats and the very feature-limited sort-of-open formats) |
| 12:08 | <gsnedders> | I dislike having to write a second personal statement |
| 12:08 | <Philip`> | gsnedders: That's what copy-and-paste is for |
| 12:09 | <gsnedders> | Philip`: I don't think that'll bode well when they have both |
| 12:09 | <gsnedders> | "We would be particularly interested to know what aspects of the Cambridge course attracted you to apply here." |
| 12:10 | Philip` | doesn't remember having to write anything like that |
| 12:10 | <Philip`> | Just say "I was attracted because I love maths" and that should be fine :-) |
| 12:11 | <gsnedders> | Philip`: The application system has totally changed since last year :) |
| 12:16 | <annevk3> | via Lachy, http://nocleanfeed.com/ wow |
| 12:17 | <Lachy> | annevk3, apparently that's been around since March, but I only just heard about it today when the news hit slashdot |
| 12:25 | <hsivonen> | how is Australian Internet censorship implmented? |
| 12:26 | <hsivonen> | IIRC, Saudi censorship is in an HTTP proxy, Finnish censorship is in DNS and Chinese in routers tricking TCP |
| 12:27 | <annevk3> | that page says that it's only a plan and that the minister has not released details and that "local" experts have all said it was technically not feasible |
| 12:28 | <Hixie> | i'm continuously baffled by people who post to lists like ac-forum or tag saying things like "we should design our standards carefully to be technically sound and architecturally solid" |
| 12:29 | <Hixie> | i mean, does anyone think we should design our standards slap dash and haphazardly without any thought given to technical design? |
| 12:30 | <annevk3> | no, but they might have the feeling that e.g. HTML5 does not meet those requirements |
| 12:30 | <zcorpan> | http://simon.html5.org/specs/html-color-attributes |
| 12:31 | <othermaciej> | Hixie: that reminds me of a story that Darin likes to tell |
| 12:31 | <othermaciej> | back in the day when he was working at Apple in the System 7 days |
| 12:31 | <othermaciej> | he was arguing with someone else over some fine point of UI design |
| 12:31 | <othermaciej> | and the other person said: |
| 12:31 | <Hixie> | annevk3: and i might think that technologies like xmlns or xlink don't either, but that doesn't make me say "we should design specs well!" it makes me give specific technical feedback |
| 12:31 | <othermaciej> | "I don't care what you say. I'll always take the side of the user!" |
| 12:32 | <Hixie> | who else's side are you going to take?! it's the _user interface_! |
| 12:32 | <othermaciej> | (as if anyone at Apple would think - "no, I'm against the user") |
| 12:32 | <Hixie> | seriously |
| 12:32 | <othermaciej> | he calls this form of argumentation "wrapping yourself in the flag" |
| 12:33 | <Hixie> | that's quite apt |
| 12:33 | <mpt> | Happens a lot in Free Software too |
| 12:33 | <Hixie> | there's a lot of argumentation of that method in us politics |
| 12:33 | <mpt> | "It would be better usability if..." |
| 12:33 | <othermaciej> | sometimes literally, e.g. the flag pin controversy |
| 12:33 | <mpt> | or, even more tellingly, "It would be better useability if..." |
| 12:33 | <Hixie> | hah |
| 12:33 | <Hixie> | anyway. bed time. |
| 12:33 | <Hixie> | nn |
| 12:34 | <annevk3> | Hixie, I guess they're not like you then :p |
| 12:34 | <othermaciej> | mpt: that kind of thing could be the prelude to a valid argument |
| 12:34 | <othermaciej> | or a wrong one |
| 12:34 | <othermaciej> | but at least it is an argument |
| 12:34 | <othermaciej> | rather than a claim to believe in some universal principle, implying anyone who disagrees with you does not |
| 12:35 | <othermaciej> | which is meant to shut down argument rather than further it |
| 12:35 | <annevk3> | Hixie, just trying to find some sort of explanation for what they're doing, not encouraging it; anyway, nn |
| 12:35 | <othermaciej> | so "you don't like this change? why are you against better usability?" would be a better example |
| 12:36 | <Philip`> | zcorpan: That colour parsing algorithm is insane |
| 12:36 | <othermaciej> | or "I believe everyone has the human right to access web content" |
| 12:36 | <mpt> | right |
| 12:36 | <mpt> | It's a vague bludgeon of an argument |
| 12:40 | <annevk3> | zcorpan, 4 and 5 are in the correct order? |
| 12:41 | annevk3 | might have asked that question before |
| 12:46 | <takkaria> | zcorpan: nice spec |
| 12:46 | <takkaria> | zcorpan: though honestly it's a bit scary if that's what browsers do |
| 13:11 | <zcorpan> | takkaria: it is what browsers do... except IE doesn't support the three-digit syntax and firefox does different things in standards mode and quirks mode |
| 13:11 | <zcorpan> | annevk3: they are |
| 13:11 | <zcorpan> | annevk3: and i think you have :) |
| 13:12 | <zcorpan> | Philip`: see topic :P |
| 13:15 | <annevk3> | i wonder why they picked this algorithm |
| 13:15 | <annevk3> | isn't there some algorithm that does the same thing but makes more sense? |
| 13:15 | <hsivonen> | interesting. Adobe ships Speex instead of AMR |
| 13:19 | <zcorpan> | annevk3: if you come up with such an algorithm, let me know :) |
| 13:22 | <jmb> | zcorpan: thanks, I now have a headache :P |
| 13:35 | <zcorpan> | jmb: sorry :( |
| 13:35 | <zcorpan> | annevk3: what lead to the conclusion of 50ms? |
| 13:36 | <zcorpan> | led |
| 13:36 | <annevk3> | it looked nice |
| 13:36 | <annevk3> | according to smaug |
| 13:36 | <zcorpan> | what looks nice? |
| 13:36 | <zcorpan> | a progress bar? |
| 13:36 | <annevk3> | the progress bar for a 1MiB download |
| 13:36 | <annevk3> | see #webapps logs |
| 13:37 | <zcorpan> | ok |
| 14:24 | <MikeSmith> | http://www.theregister.co.uk/2008/10/16/android_kill_switch/ |
| 14:25 | <MikeSmith> | "Google may discover a product that violates the developer distribution agreement ... in such an instance, Google retains the right to remotely remove those applications from your device at its sole discretion." |
| 14:30 | <jcranmer> | o_O |
| 14:33 | <zcorpan> | it seems to me that the pixelratio attribute is the same as html-level accessibility features for video |
| 14:34 | <zcorpan> | although pixelratio is a lot simpler to fix than accessibility |
| 14:34 | <zcorpan> | and maybe more likely to be fixed |
| 14:34 | <zcorpan> | but perhaps it would be better to force them to be fixed in the video itself |
| 14:36 | <zcorpan> | a service to fix pixelratio of videos could also provide adding accessibility features |
| 14:37 | <annevk3> | something about tools will save us |
| 14:58 | <zcorpan> | annevk3: that's the argument being used about accessibility feautes, no? |
| 14:58 | <zcorpan> | practical problems with rdfa http://www.sitepoint.com/forums/showthread.php?t=577303 |
| 14:58 | <zcorpan> | (how do you style it?) |
| 15:00 | <Dashiva> | Ask the XHTML2 WG to do something? That's funny |
| 15:00 | <annevk3> | zcorpan, yeah, I argued against that position yesterday |
| 15:01 | <zcorpan> | annevk3: ok. (sorry if i don't read accessibility discussions carefully :P) |
| 15:01 | <zcorpan> | (or at all) |
| 15:01 | <annevk3> | it was just on IRC, but fair enough |
| 15:02 | <annevk3> | otoh, Hixie said that without tools including e.g. subtitles in an MPEG stream on the fly was easy |
| 15:02 | <annevk3> | I don't really know enough about it myself to judge |
| 15:04 | <zcorpan> | i presume fixing pixelratio is easier |
| 15:04 | <zcorpan> | than writing and including subtitles |
| 15:04 | <zcorpan> | s/writing and/ |
| 15:05 | <zcorpan> | s/writing and// |
| 15:05 | <annevk3> | adding bolt-on accessibility to HTML is not an easy task, no |
| 15:06 | <zcorpan> | i mean, i presume fixing the pixelratio in the video resource is easier (or just as easy) as adding subtitles |
| 15:06 | <annevk3> | no idea |
| 15:07 | <annevk3> | I don't really see why HTML needs to provide the accessibility features though |
| 15:07 | <annevk3> | people could use SMIL |
| 15:08 | <annevk3> | otoh, SMIL is fugly |
| 15:09 | <onitunes> | SMIL: from a time when XML was cool |
| 15:09 | <onitunes> | c.f. SVG |
| 15:13 | <hsivonen> | "Use SMIL" is a good solution only if browsers support it. |
| 15:14 | <hsivonen> | I'm not convinced that supporting it outside SVG would be a good use of developer time. |
| 15:17 | <zcorpan> | so how about "use SVG"? |
| 15:18 | <zcorpan> | or "use scripting and css" |
| 15:19 | <hsivonen> | does an SVG file map reasonably to a timeline? with scripts and all |
| 15:19 | <hsivonen> | I don't know if SVG has an easy mechanism for overlaying captions |
| 15:20 | <hsivonen> | is there a comprehensive list of W3C working groups, incubators, etc.? |
| 15:21 | <zcorpan> | i guess an SVG file would map equally well as SMIL would |
| 15:21 | <hsivonen> | zcorpan: can SMIL have JS? |
| 15:22 | <zcorpan> | hsivonen: dunno |
| 15:22 | <annevk3> | I think so |
| 15:28 | <hsivonen> | If I link to another HTML page authored by someone else, am I responsible for making it accessible? |
| 16:20 | myakura | is glad to see the new jplayout draft published so he can now understand and possibly comment on <ruby> |
| 16:21 | annevk3 | regrets his last e-mail, but not too much |
| 16:27 | <hsivonen> | myakura: I don't find a link to a public draft on the home page of the task force. Do you have a URL? |
| 16:29 | <myakura> | hsivonen: http://www.w3.org/TR/2008/WD-jlreq-20081015/ (found via the home page) |
| 16:29 | <myakura> | also congrats for media queries lc! |
| 16:30 | <hsivonen> | myakura: I see. I thought "Requirements" was something else. thanks |
| 16:30 | <annevk3> | is media queries announced yet? |
| 16:30 | <annevk3> | anyways, thanks :) |
| 16:30 | annevk3 | goes to fetch some food |
| 16:33 | <myakura> | not sure it's annouced, though it seems it's now publicly available http://www.w3.org/TR/2008/WD-css3-mediaqueries-20081015/ |
| 17:10 | <annevk3> | eric_carlson, just loop would be unimplementable |
| 17:11 | <eric_carlson> | annevk3: why? |
| 17:11 | <annevk3> | eric_carlson, way too complex |
| 17:12 | <annevk3> | actually, I should say, way too simple |
| 17:13 | <annevk3> | anyways, I should go |
| 17:13 | <Philip`> | By which you mean, you should stay? |
| 17:14 | <eric_carlson> | annevk3: ah, perhaps my sarcasm filter is dysfunctional this morning |
| 18:50 | <gsnedders> | BenMillard: Quelle heure arrives tu? |
| 18:50 | <gsnedders> | (Does that make sense, anyone?) |
| 20:43 | <Philip`> | http://tech.slashdot.org/article.pl?sid=08/10/16/1325215 |
| 20:44 | <Dashiva> | 'Looks good in Internet Explorer and doesn't seem to crash Firefox or Opera' is not a standard. |
| 20:44 | <Dashiva> | ^ I disagree |
| 20:44 | <blooberry> | philip`: trust the media to make blanket statements that didn't say what the original article said. 8-} |
| 20:47 | <Philip`> | blooberry: I'm happy to trust them to do that :-) |
| 20:55 | <gsnedders> | Didn't Hixie have a far lower percentage? |
| 21:05 | <blooberry> | gsnedders: For validation? He didn't run validation in his main study though right? (http://code.google.com/webstats/) |
| 21:06 | <gsnedders> | blooberry: I don't think it was in his main study, but it was if anything over a bigger number of docs, and it was only looking for basic syntax errors |
| 21:06 | <gsnedders> | blooberry: But I think it was < 1% without any |
| 21:07 | <blooberry> | so, basically a well-formedness check? |
| 21:07 | <gsnedders> | Well, well-formedness doesn't exist for HTML :P |
| 21:07 | <gsnedders> | But, yeah, basically |
| 21:07 | <blooberry> | he scanned deep URLs as well as surface and there are a loooot of deep URLs. MAMA's URL set for this report was primarily DMoz and it is heavily skewed to surface URLs. |
| 21:13 | <blooberry> | he told me once that the majority of his analysis set was deep URLs by a wide margin |
| 21:19 | <weinig> | Hixie: ping |
| 21:19 | <Hixie> | yo |
| 21:24 | <weinig> | Hixie: hey, I was wondering if you had decided what to do with multifile input type=file |
| 21:24 | <weinig> | Hixie: ie. use multiple attribute perhaps |
| 21:24 | <weinig> | Hixie: min/max as per WF2 |
| 21:24 | <Hixie> | i'll probably use multiple="" |
| 21:25 | <weinig> | Hixie: cool |
| 21:25 | <Hixie> | if you want to implement something, go with that, and send feedback to the list reminding me |
| 21:25 | <weinig> | Hixie: will do |
| 21:25 | <Hixie> | thanks |
| 21:25 | <weinig> | Hixie: do think it is reasonable for the UA to change the look (probably the height being the big issue) of the input when you have multiple set for file? |
| 21:26 | <Hixie> | yes |
| 21:26 | <weinig> | Hixie: great to know |
| 21:26 | <Hixie> | we'll have to standardise on something though |
| 21:26 | weinig | nods |
| 21:26 | <Hixie> | might help to see what opera does |
| 21:26 | <Hixie> | they might have implemented type=file min/max already |
| 21:26 | <weinig> | opera uses min/max |
| 21:26 | <weinig> | and it looks just like the old control for the most part |
| 21:27 | <Hixie> | k |
| 21:27 | <Hixie> | how do they show what's selected? |
| 21:28 | <weinig> | in a quoted list (I think comma separated) where the file name would go in the single file case |
| 21:28 | <weinig> | I don't think we would implement it like that |
| 21:28 | <weinig> | as it hides a lot of data |
| 21:29 | <Hixie> | k |
| 21:35 | <Lachy> | Opera's UI for multiple file inputs isn't very usable at all |
| 22:44 | <annevk3> | all cool things belong to us: http://twitter.com/Thracks/statuses/962799479 |
| 22:45 | annevk3 | also sees "HTML5 geolocation" quite often |
| 22:46 | <roc> | erm, Safari 3.1 had @font-face support |
| 22:47 | <roc> | nice demo though |
| 22:49 | <roc> | oh, those are jresig's demos, heh |
| 22:52 | <annevk3> | they look like demos howcome used to show around |
| 22:52 | <annevk3> | fwiw |
| 22:53 | <roc> | I hope those fonts are properly licensed! |
| 22:55 | <annevk3> | I believe howcome used free fonts only, dunno about jresig |