| 00:00 | <Hixie> | dglazkov: what i just described was just css. :-) |
| 00:00 | <zewt> | at least, that's what it gives me if I load a file into FF from a UNC path |
| 00:00 | <Hixie> | dglazkov: so clearly it can be described as css :-) |
| 00:00 | <TabAtkins> | The 'appearance' property counts as 'magic'. ^_^ |
| 00:01 | <Hixie> | well HTML defines everything in terms of XBL |
| 00:01 | <Hixie> | so you could just implement XBL instead :-) |
| 00:01 | <dglazkov> | Hixie: oh right. I like the idea of -webkit-direction |
| 00:02 | <dglazkov> | Hixie: but I think the authors would much rather do: meter { -webkit-direction: horizontal; } |
| 00:02 | <Hixie> | dglazkov: well then have the default -webkit-direction value be 'auto' |
| 00:02 | <dglazkov> | Hixie: meter { width: 200px; height: 10px; } |
| 00:04 | <dglazkov> | Hixie: in order for the box-sensing to work, they'd have to style _more_ than in explicit setting |
| 00:05 | <Hixie> | how so? |
| 00:05 | <dglazkov> | meter { direction: horizontal } -- done |
| 00:05 | <zewt> | AryehGregor: not that it answers your question about standards (no idea), but Chrome and Opera use the much saner file://host/path (havn't tried IE9) |
| 00:05 | <Hixie> | dglazkov: what is done? |
| 00:05 | <dglazkov> | meter { width: somevalueIneedtoknow, height: someothervalue; } |
| 00:05 | <Hixie> | dglazkov: what is the use case you're trying to solve here? |
| 00:06 | <dglazkov> | Hixie: I am reasoning against auto-sensing the dimensions |
| 00:06 | <dglazkov> | Hixie: dimensions are a poor way of doing this |
| 00:06 | <Hixie> | what is "this"? |
| 00:06 | <dglazkov> | determining the orientation of control |
| 00:07 | <dglazkov> | you don't actually mean what you say. The author wants to say: "I want this to be horizonal" |
| 00:07 | <dglazkov> | so they have to start measuring stuff |
| 00:07 | <dglazkov> | instead, they just need to be able to say "horizonal" |
| 00:07 | <Hixie> | dimensions are the best way of determining the default orientation of control, they are only going to want to have a vertical meter if they are sizing their meter to be vertical. |
| 00:07 | <dglazkov> | as in <meter orientation="horizonal"> |
| 00:08 | <dglazkov> | you are saying that they are the best, but why? |
| 00:08 | <dglazkov> | why is it easier than just explicitly stating the orientation? |
| 00:08 | <Hixie> | authors are far more likely to be giving the dimensions of their control and be disappointed that the control is now in a stupid direction (e.g. taller than wide but still horizontal), than they are to care about the direction of the control but not its dimensions. |
| 00:08 | <dglazkov> | that's just hearsay |
| 00:08 | <Hixie> | not saying something is trivially easier than saying something. |
| 00:09 | <dglazkov> | you are still saying something |
| 00:09 | <Hixie> | my argument has as much validity as the one you are making :-) |
| 00:09 | <zewt> | it seems like a sensible default, as long as it can be overridden |
| 00:09 | <dglazkov> | no, it doesn't |
| 00:09 | <Hixie> | you're saying the opposite of what i'm saying with as much evidence |
| 00:09 | <dglazkov> | you are adding magic |
| 00:09 | <dglazkov> | where I am not |
| 00:09 | <dglazkov> | therefore my argument is better :) |
| 00:09 | <Hixie> | you say magic, i say usability :-) |
| 00:09 | <Hixie> | therefore my argument is better :-) |
| 00:10 | <dglazkov> | ok, let's start from a few steps back |
| 00:10 | <Hixie> | k |
| 00:10 | <dglazkov> | when I want to specify orientation of a control, do I think a) dimensions or b) orientation? |
| 00:10 | <dglazkov> | I would say orientation |
| 00:11 | <Hixie> | sure |
| 00:11 | <Hixie> | when I want to specify dimensions of a control, do I think a) dimensions or b) orientation? |
| 00:11 | <Hixie> | I would say dimensions |
| 00:11 | <dglazkov> | yup |
| 00:11 | <dglazkov> | and you are conflating the two |
| 00:12 | <Hixie> | i said the same as you did with one word switched! |
| 00:12 | <dglazkov> | you proved my point! |
| 00:12 | <zewt> | let's exclaim things! |
| 00:12 | <Hixie> | dglazkov: i really don't know what your point is, so that's surprising to me :-) |
| 00:12 | <dglazkov> | you are conflating setting dimensions with setting orientation. |
| 00:12 | <dglazkov> | and what I am saying is that they should be two separate things |
| 00:13 | <Hixie> | i'm saying that when authors change the dimensions, they will almost always what the orientation to switch to match. |
| 00:13 | <dglazkov> | because when the author wants to set dimensions, he doesn't expect to set both dimension and orientation |
| 00:13 | <Hixie> | EXACTLY |
| 00:13 | <Hixie> | which is why when you set the dimensions, the orientation should automatically follow |
| 00:14 | <zewt> | i think he meant: he doesn't expect both dimension and orientation to be set |
| 00:14 | <Hixie> | then i completely disagree |
| 00:14 | <Hixie> | when the author wants to set dimensions, he doesn't expect to have to set both dimension and orientation |
| 00:14 | <dglazkov> | Hixie: there is nothing on the Web that behaves like that |
| 00:14 | <dglazkov> | Hixie: when the author sets dimensions of a div, he doesn't expect the div to change orientation |
| 00:15 | <Hixie> | everything on the web behaves like this. You put content in a table, it automatically sizes to fit it. You put a bunch of floats next to each other, they automatically wrap to avoid each other. Etc. |
| 00:15 | <dglazkov> | wrap and fit are totally different from orientation |
| 00:15 | <dglazkov> | nothing changes orientation |
| 00:16 | <Hixie> | what would have needed to change orientation? |
| 00:16 | <zewt> | either way you'd still be able to set the orientation explicitly, right? (eg. if you really do want a 10x100 progress bar that fills horizontally) |
| 00:16 | <dglazkov> | when an author builds a page with a meter, he/she thinks of orientation, not dimensions |
| 00:17 | <dglazkov> | dimensions come as a forcing function to change orientation |
| 00:17 | <zewt> | (eg. the auto argument is only a default, not for not having an orientation style at all?) |
| 00:17 | <dglazkov> | or at least it will be, according to the spec today |
| 00:17 | <Hixie> | I disagree with "when an author builds a page with a meter, he/she thinks of orientation, not dimensions" |
| 00:17 | <dglazkov> | in a normal flow document, dimensions aren't even necessary |
| 00:17 | <dglazkov> | and you're making the author think of dimensions |
| 00:18 | <dglazkov> | <p>This restaurant is awesome</p> |
| 00:18 | <dglazkov> | <meter> |
| 00:18 | <AryehGregor> | Agreed that you'd often want to specify orientation without dimensions. |
| 00:18 | <Hixie> | when an author builds a page with a meter, he/she thinks of dimensions, not orientation. |
| 00:18 | <AryehGregor> | In many cases, the dimensions aren't going to be important. |
| 00:18 | <dglazkov> | Hixie: not at all |
| 00:18 | <AryehGregor> | Unless you're building a carefully sized layout. |
| 00:18 | <dglazkov> | AryehGregor: exactly. |
| 00:18 | <zewt> | when I (an author :) build a page with a meter, I think of both, together |
| 00:18 | <AryehGregor> | Generally you just stick stuff in and let it be whatever size it is. |
| 00:18 | <Hixie> | can you show me some examples with vertical meters? |
| 00:18 | <zewt> | (not with <meter> yet, but in the manual progress meters I've implemented) |
| 00:18 | <Hixie> | some real pages? |
| 00:19 | <AryehGregor> | I don't care much what size my inputs are, for instance. |
| 00:19 | <Hixie> | all the pages i've seen have horizontal meters with specified sizes. |
| 00:19 | <Hixie> | i can't think of a single page with a vertical meter. |
| 00:19 | <AryehGregor> | They only have specified sizes because they kind of have to if you're hacking them up with <img>s. :) |
| 00:19 | <dglazkov> | Hixie: I think you're trying to defer discussion by making me do some grungy work :) I know this tactic |
| 00:19 | <zewt> | (not arguing either way--neither way of doing it seems particularly better or worse to me) |
| 00:19 | <AryehGregor> | It's certainly true that vertical meters seem like they'd be less common. |
| 00:19 | <dglazkov> | Hixie: can you show me one page that needs auto-sizing controls? |
| 00:19 | <AryehGregor> | Horizontal meters seem like they're a much bigger use-case. |
| 00:19 | <Hixie> | dglazkov: no, i'm trying to base our decisions on real world data |
| 00:20 | <Hixie> | dglazkov: what do you mean by "auto-sizing controls"? |
| 00:20 | <dglazkov> | Hixie: controls that change orientation based on their size |
| 00:20 | <zewt> | here's one case where auto-orientation would be funky: a meter with a CSS animation to animate its width from 0 to full-size |
| 00:21 | <zewt> | if it's automatically oriented, it'd briefly be vertical at the start of the animation |
| 00:21 | <dglazkov> | Hixie: real-world data is hard to come by when meter is a brand new baby |
| 00:22 | <dglazkov> | Hixie: but pretty much any statistical bar chart could be made with meters |
| 00:22 | <dglazkov> | vertical ones |
| 00:22 | <AryehGregor> | dglazkov, I assume he means pages that hack up their own meters. |
| 00:23 | <AryehGregor> | Personally, I'm unconvinced that <meter> is worth implementing at all. But that's me. |
| 00:24 | <dglazkov> | and assuming we have a statistical bar chart, I can see it being implemented as meter { float: left; orientation: vertical } |
| 00:24 | <dglazkov> | no need to fiddle with dimensions |
| 00:25 | <dglazkov> | I guess what I am saying is: there is no proof that size-sensing is a useful feature. And you're making browser peeps run in circles because you think it's cool |
| 00:25 | <dglazkov> | less complexity |
| 00:26 | <dglazkov> | is better |
| 00:27 | <Hixie> | dglazkov: ok, finally was able to find the right page in the Cocoa documentation. The NSSlider control automatically orients itself based on its size: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSlider_Class/Reference/Reference.html#//apple_ref/occ/cl/NSSlider (search for isVertical) |
| 00:28 | <Hixie> | dglazkov: not really sure how one would find a page that "needs" this since by definition any page could work around the lack of this feature. The idea here is that the feature saves author time. |
| 00:28 | <dglazkov> | Hixie: yup. And it's a great feature for fixed-positioned platforms. But for the web, I highly doubt it |
| 00:28 | <Hixie> | dglazkov: why? |
| 00:28 | <Hixie> | dglazkov: it's even MORE useful on the web |
| 00:29 | <dglazkov> | Hixie: because dimensions play lesser role |
| 00:29 | <dglazkov> | Hixie: as I demonstrated in my bar chart example, I don't even need to know dimensions |
| 00:29 | <AryehGregor> | Web pages don't use fixed sizes much. |
| 00:29 | <AryehGregor> | Stuff is fluid. |
| 00:29 | <gsnedders> | Life is fluid. |
| 00:29 | <Hixie> | i wish that were true |
| 00:30 | <Hixie> | but everything has dimensions on the web |
| 00:30 | <AryehGregor> | Mostly not author-specified unless you force them to. |
| 00:30 | <dglazkov> | Hixie: as you resize the page, your constraints can change. Do you expect meters to be changing orientation too? |
| 00:30 | <AryehGregor> | Authors like things that auto-size, like tables and floats. |
| 00:30 | <dglazkov> | Hixie: that's just not true at all |
| 00:30 | <AryehGregor> | They mostly only specify fixed sizes when their layout requires them to use absolute positioning due to CSS limitations, or things like that. |
| 00:30 | <dglazkov> | Hixie: look at Wikipedia. What percentage of the layout is based on actual dimensions? |
| 00:30 | <AryehGregor> | dglazkov, the sidebar is fixed-width. |
| 00:30 | <Hixie> | dglazkov: if the meter gets so narrow that it's taller than wide, yes, it would be a usuability win if it became more readable by automatically switching direction. |
| 00:30 | <AryehGregor> | So is the stuff at the top. |
| 00:31 | <AryehGregor> | It's all absolute positioning. |
| 00:31 | <AryehGregor> | Infoboxes are fixed-width. |
| 00:31 | <AryehGregor> | Images are fixed-width. |
| 00:31 | <AryehGregor> | Lots of stuff is. |
| 00:31 | <Hixie> | dglazkov: the meter on the wikipedia page (when they ask for money) is fixed-width (as a % of page width), iirc |
| 00:31 | <AryehGregor> | Yeah, percentages are useful for things like that. |
| 00:31 | <AryehGregor> | Not if it's inline with the page text. But lots of meters aren't. |
| 00:32 | <dglazkov> | alright folks, this was lots of fun :) |
| 00:32 | <dglazkov> | but I gotta go |
| 00:32 | <dglazkov> | unfortunately |
| 00:32 | <dglazkov> | this discussion reminded me of the old days in college |
| 00:32 | <Hixie> | AryehGregor: if it's inline with the page, you're not going to change its orientation either |
| 00:33 | <AryehGregor> | Meters like that are unlikely, yeah, unless you're constructing a bar graph or something. |
| 00:33 | <AryehGregor> | But then it seems really unlikely you'd want any kind of default meter appearance. |
| 00:33 | <Hixie> | making a bar graph with <meter>s is wacky |
| 00:33 | <AryehGregor> | But arguing from use-cases here is kind of weak because, as I said, the use-cases for a <meter> element are really very limited. |
| 00:33 | <Hixie> | yeah the main use case for <meter> is "try to reduce the number of people who abuse <progress> for meters" |
| 00:34 | <Hixie> | but the same discussion applies to <progress> |
| 00:34 | <AryehGregor> | Which also seems like it has very limited use-cases, as an element. |
| 00:34 | <Hixie> | well it has one use case |
| 00:34 | <Hixie> | showing a progress bar :-) |
| 00:35 | <AryehGregor> | Yes, but how many sites will actually want to use a system default progress bar? |
| 00:35 | <Hixie> | enough :-) |
| 00:35 | <zewt> | depends on if UAs style it reasonably or hideously, heh |
| 00:35 | <Hixie> | i've already written pages that use it myself, in fact |
| 00:35 | <Hixie> | e.g. http://hixie.ch/tests/adhoc/html/parsing/encoding/all.html |
| 00:36 | <Hixie> | in fact i may have used <progress> more than <aside> |
| 00:36 | <Hixie> | :-) |
| 00:37 | <gsnedders> | neither progress/meter can represent something which has a segment that is "done", and another segment that is "in progress" (as well as "not started"), right? |
| 00:37 | <Hixie> | example? |
| 00:39 | <gsnedders> | Hixie: An automated testing system, and tests been run, being run, yet to run. |
| 00:41 | <Hixie> | isn't that just many <progress>es? |
| 00:49 | <gsnedders> | Hixie: So what? One of tests run (out of total tests) and one of tests being run (out of total tests)? |
| 00:50 | <Hixie> | gsnedders: i don't fully understand what you're describing, so i'm not sure. |
| 00:50 | <Hixie> | gsnedders: if you have a bunch of tests and they can each have progress, then i'd guess each one would have a <progress> |
| 00:50 | <Hixie> | gsnedders: if you have a bunch of tests and you want to indicate how many are "on", then a <meter> is appropriate |
| 00:51 | <Hixie> | gsnedders: if you have a bunch of tests running and you want to indicate their aggregate progress, <progress> is appropriate |
| 00:51 | <Hixie> | hth |
| 01:15 | <TabAtkins> | What. The. Hell. Can someone who knows PHP look at this and tell me why I'm clearly hallucinating, because there's no way this behavior could actually be happening? http://www.xanthir.com/test.php |
| 01:19 | <gsnedders> | TabAtkins: $arr['4300'] != $arr[4300] |
| 01:19 | <gsnedders> | TabAtkins: Also, are you sure the value genuinely isn't NULL? What's error_reporting set at? |
| 01:19 | <TabAtkins> | gsnedders: Well, no, apparently they *are* the same. But *neither* will retrieve the element with the key '4300'. |
| 01:20 | <hober> | TabAtkins: weird |
| 01:21 | <TabAtkins> | The array is constructed by just reading in a big JSON blob, and the '4300' entry definitely exists here in the json. |
| 01:25 | <TabAtkins> | And now isset() is reporting that the index isn't set, despite it being right there in the array_keys() result. |
| 01:27 | <gsnedders> | TabAtkins: isset returns false if the value is null |
| 01:27 | <gsnedders> | TabAtkins: see array_key_exists |
| 01:27 | <TabAtkins> | omg |
| 01:29 | <TabAtkins> | Yup, array_key_exists('4300',$arr) returns false, despite '4300' showing up right there in array_keys($arr). |
| 01:29 | <TabAtkins> | W.T.F. |
| 01:31 | <TabAtkins> | And a foreach over the array shows the missing key. |
| 01:32 | <Hixie> | is there anything in the platform that returns a Blob for some generated data yet? |
| 01:32 | <Hixie> | i'm trying to work out what to call the method on StreamRecorder that returns (via callback) a Blob containing the recorded data |
| 01:32 | <Hixie> | it used to be stop() but that doesn't make sense since it doesn't actually stop anything |
| 01:32 | <Hixie> | getBlob(callback)? |
| 01:33 | <hober> | getRecordedData(cb) |
| 01:34 | <Hixie> | var r = stream.record(); ... r.getRecordedData(function(blob) { use(blob) }); ? |
| 01:34 | <Hixie> | i guess that works |
| 01:34 | <Hixie> | vs var r = stream.record(); ... r.getBlob(function(blob) { use(blob) }); |
| 01:35 | <TabAtkins> | Jeez, if I do a foreach over $arr, not only does the key exist (though the array claims it doesn't) but the value is an object (not a NULL). omg. |
| 01:38 | <boogyman> | TabAtkins: fail lol :( |
| 01:39 | <zewt> | filesystem api is just getFile for File, fwiw, getBlob would be in line with that |
| 01:40 | <boogyman> | TabAtkins: 4300 isn't a "key" it's the value of $arr[10] |
| 01:40 | <TabAtkins> | boogyman: Look closer. That first array is the result of array_keys |
| 01:41 | <TabAtkins> | Which produces an array whose values are the keys of the passed array. |
| 01:41 | <TabAtkins> | I'm not outputting $arr directly, because it's huge. |
| 01:42 | <Hixie> | zewt: yeah but there we're getting a file (which happens to be a File), whereas here we're getting recorded data (which happens to be a Blob) |
| 01:42 | <Hixie> | zewt: so it's not a clear precedent |
| 01:42 | <Philip`> | TabAtkins: Does it fail for all keys that are /^\d+$/ ? |
| 01:43 | <TabAtkins> | Philip`: Yes. |
| 01:43 | <TabAtkins> | And I think I may know why... |
| 01:44 | <Philip`> | Bug in the JSON parser that tries to use $arr as both a string-indexed and numeric-indexed array, when PHP only supports them being one or the other? |
| 01:44 | <AryehGregor> | PHP supports the same array being both. |
| 01:45 | <AryehGregor> | I think what they actually do is just cast numeric indexes to strings. |
| 01:45 | <AryehGregor> | $ php -r '$arr = array(); $arr[1] = "foo"; $arr["1"] = "bar"; var_dump($arr[1]);' |
| 01:45 | <AryehGregor> | string(3) "bar" |
| 01:45 | <TabAtkins> | Okay, I was hoping that maybe it was a property rather than an array, but no, property_exists throws a warning at me. |
| 01:45 | <zewt> | is the only place that actually creates Blobs right now Blob.slice()? (via File) |
| 01:45 | <TabAtkins> | AryehGregor: I know! It works fine for arbitrary arrays! |
| 01:46 | <AryehGregor> | TabAtkins, what code is the problem? |
| 01:47 | <TabAtkins> | My json-backed database. I load a json file into an array (what I'm calling $arr on the test.php page), and then operate on it. |
| 01:47 | <Hixie> | zewt: XHR2 probably too |
| 01:47 | <Hixie> | ok i'm outta here. bbl. |
| 01:47 | <AryehGregor> | What functions do you use to load the array? |
| 01:47 | <TabAtkins> | json_decode |
| 01:48 | <AryehGregor> | Just json_decode($str), with no further parameters specified? |
| 01:48 | <Philip`> | TabAtkins: http://bugs.php.net/bug.php?id=53130 ? |
| 01:48 | <TabAtkins> | AryehGregor: Yup. |
| 01:48 | <TabAtkins> | Philip`: ...yup, that's it. |
| 01:49 | <AryehGregor> | Yay PHP. |
| 01:49 | <AryehGregor> | Try doing json_decode($str, true). |
| 01:49 | <AryehGregor> | Apparently that gives you arrays. |
| 01:49 | <AryehGregor> | Which makes way more sense, in PHP. |
| 01:50 | <TabAtkins> | The problem is that I don't want objects on the lower level to be coerced to arrays. |
| 01:50 | <TabAtkins> | (I find object access more aesthetically pleasing than array access with string keys.) |
| 01:50 | <AryehGregor> | http://us.php.net/language.types.array#language.types.array.casting |
| 01:50 | <AryehGregor> | "If an object is converted to an array, the result is an array whose elements are the object's properties. The keys are the member variable names, with a few notable exceptions: integer properties are unaccessible; private variables have the class name prepended to the variable name; protected variables have a '*' prepended to the variable name. These prepended values have null bytes on either side. This can result in some unexpected behaviou |
| 01:50 | <AryehGregor> | r:" |
| 01:50 | <AryehGregor> | Wow, PHP is freaking broken. |
| 01:50 | <zewt> | news flash |
| 01:50 | <TabAtkins> | Oh my god. |
| 01:50 | <AryehGregor> | "The above will appear to have two keys named 'AA', although one of them is actually named '\0A\0A'." |
| 01:51 | <TabAtkins> | This is the dumbest crap I have ever seen. |
| 01:51 | <zewt> | also world round, universe large |
| 01:51 | <AryehGregor> | TabAtkins, this is PHP. |
| 01:52 | <TabAtkins> | Okay, the whole reason I was casting the decoded object into an array anyway was so I could use array_keys on it. |
| 01:52 | <TabAtkins> | But I didn't know there was a get_object_vars, which should probably work too. |
| 01:53 | <zewt> | i wish Python was more amenable to templating, which would make it easier for the sort of quick web hacks that PHP is used for |
| 01:53 | <zewt> | that's one thing its tab syntax is very bad at |
| 01:53 | <TabAtkins> | But seriously this is the brokenest thing I have ever seen PHP do. ARgh. |
| 01:54 | <TabAtkins> | Going home now, I'll fix this tonight. |
| 01:54 | <Philip`> | s/fix/rewrite in a real language/ ? |
| 01:54 | <zewt> | heh |
| 01:55 | <TabAtkins> | Unfortunately, no. zewt's right that PHP's templating ability still makes it the easiest thing to develop small sites in. |
| 01:55 | <zewt> | i can't take any language seriously now that uses $basic $variable $prefixes |
| 01:55 | <zewt> | feels like someone's sneezed all over my code |
| 01:56 | <Philip`> | TabAtkins: CGI + Perl works for that :-) |
| 01:57 | <zewt> | perl is not really an improvement :) |
| 01:57 | <TabAtkins> | yeah... |
| 01:57 | <zewt> | "waiter, there seems to be glass in my soup" "would you like staples instead?" |
| 01:59 | <Philip`> | PHP is weird and illogical; Perl is weirdly logical |
| 01:59 | <Philip`> | Both make you say "why on Earth does it work like this?", but Perl usually has an answer |
| 01:59 | <zewt> | i don't use either, except for very limited, mostly throwaway hacks |
| 02:00 | <zewt> | php for quick server-side tests and very small mini-pages; perl for sed/awk-ish one-liners |
| 02:01 | <AryehGregor> | TabAtkins, if this is the most broken thing you've seen in PHP, you haven't programmed PHP enough. |
| 02:01 | <zewt> | my take on perl is it's the only language that I've used, on and off, for over a decade, and still get headaches from the basic syntax |
| 02:01 | <AryehGregor> | How about supporting getters on objects, which return null without logging any warning if they're called recursively? |
| 02:02 | <zewt> | i consider myself competent enough to place the blame on perl and not myself, heh |
| 02:04 | <boogyman> | zewt: lol, as long as you believe that :P |
| 02:05 | <zewt> | versus understanding more or less all of python's syntax in a couple days :P |
| 02:07 | <roc> | zewt: you're going to love CSS variables! |
| 02:07 | <zewt> | do i have to :( |
| 02:08 | <boogyman> | roc: might need to wait a couple yrs for that |
| 07:55 | <annevk> | morning |
| 07:55 | <annevk> | AryehGregor, we nuked CDATASection in favor of just Text |
| 08:14 | <annevk> | http://www.w3.org/TR/progress-events/ Last Call |
| 08:14 | <annevk> | better comment by June 1 or we'll ignore you |
| 08:14 | <annevk> | (but not really, but still it would be nice if you did) |
| 08:16 | <zcorpan> | http://www.aminutewithbrendan.com/pages/20110308 - pretty sure we can't add an operator called 'div' |
| 08:28 | jgraham | advises caution around arguments that boil down to "PHP is the easiest language because it lets me mix output and code freely" |
| 08:29 | <jgraham> | Really Python + any template library will save you a lot of badness if the site ever grows |
| 08:29 | <jgraham> | In somewhat related news |
| 08:30 | <jgraham> | Hixie: The use case gsnedders was failing to explain was the "we have x% of tests done and a further y% currently assigned to test machines" |
| 08:31 | <jgraham> | "and we want a progress bar that looks like [xxxxxyy ] |
| 08:31 | <jgraham> | so that one can see at a glance how much is done and how much will be done soon" |
| 08:33 | <annevk> | what to do in the day before last |
| 08:33 | <annevk> | I think I'm pretty much done with everything I wanted and it seems kind of late to start something new... |
| 08:42 | <matijsb> | go spinning :) |
| 08:52 | <annevk> | hehe |
| 08:52 | <annevk> | if I could go in an hour from now... |
| 09:08 | <annevk> | http://dev.twitter.com/doc/get/statuses/user_timeline has an undocumented parameter (and maybe more) called exclude_replies which can be set to true |
| 09:13 | <annevk> | no idea how to give feedback on that website so I'll just leave it here in case someone here works for twitter or knows someone who does |
| 09:14 | <annevk> | (oh, and please don't kill the feature, it's useful :) ) |
| 09:14 | <zcorpan> | Hixie: role=presentation on <table> implies role=presentation on all the rows and cells as well |
| 09:57 | <annevk> | MikeSmith, all okay? |
| 09:59 | <MikeSmith> | yeah, not dead |
| 09:59 | <MikeSmith> | yet |
| 10:01 | <annevk> | good good |
| 10:33 | <annevk> | myakura is also ok it seems :) |
| 10:40 | <annevk> | I guess I should do expenses |
| 10:40 | <annevk> | :/ |
| 10:46 | <Hixie> | zcorpan: ok good. i assumed it'd be something like that, or the decision would be even more ridiculous. |
| 10:47 | <Hixie> | anyone in the bay area, if you haven't heard yet, tsunami is expected to hit us at 8:08am so stay half-a-mile or more away from the coast. |
| 10:47 | <Hixie> | anyone else in the pacific region, check local broadcasts. |
| 10:47 | <Hixie> | MikeSmith: you ok? |
| 10:48 | <MikeSmith> | yeah |
| 10:48 | <MikeSmith> | things remarkably undamaged here outside |
| 10:48 | <MikeSmith> | despite a pretty good amount of shaking |
| 10:48 | <annevk> | I saw this on twitter |
| 10:49 | <annevk> | """The headline you won't be reading: "Millions saved in Japan by good engineering and government building codes". Buts it's the truth.""" |
| 10:50 | <Hixie> | MikeSmith: good to hear. the video we're seeing on the news is pretty scary., |
| 10:50 | jgraham | wonders what all the free-market-liberterian-kooks think about building codes |
| 10:50 | <MikeSmith> | yeah, up north in Sendai things were worse |
| 10:51 | <MikeSmith> | with the tsunami |
| 10:51 | <Peter-> | I saw the video of the tsunami progressing inland on the news, that's horrible |
| 10:52 | <Hixie> | i saw one video with a huge ball of fire being pushed along by the water, that was one of hte most disturbing images |
| 10:54 | <MikeSmith> | yeah, I think a refinery in Chiba caught fire |
| 10:57 | <wilhelm> | Looks like everyone at Opera's Tokyo office and my other friends in town are all okay. |
| 10:57 | <Hixie> | good to know |
| 11:05 | <Rik`> | same for Mozilla Japan |
| 11:06 | <Rik`> | the office has been shaken http://www.flickr.com/photos/dynamozilla/5516432243/in/set-72157626116876855/ |
| 11:08 | <wilhelm> | http://a4.sphotos.ak.fbcdn.net/hphotos-ak-snc6/190668_10150438508240355_802015354_17665227_4360168_n.jpg (c: |
| 11:15 | <jgraham> | Hixie: When one "Remove any tasks queued by the history traversal task source." I assume that is irrespective of the document associated with the task? |
| 11:16 | <jgraham> | e.g. if I pushState in an iframe it will clear a navigation queued in the parent? |
| 11:16 | <jgraham> | Why is clearing the navigation desirable? |
| 11:35 | <myakura> | it feels like i'm getting seasick.. |
| 11:59 | <hsivonen> | good to see that myakura and MikeSmith are apparently at relatively safe locations |
| 12:43 | <jgraham> | heycam: So it it not clear to me exactly what it means in WebIDL to "implement the interface" |
| 12:44 | <jgraham> | But the real question I have is that if I have, for example, an exception that implements DOMException, what should |
| 12:44 | <jgraham> | exception instanceof other_window.DOMException |
| 12:44 | <jgraham> | return? |
| 12:46 | jgraham | assumes false since the exception doesn't "implement the interface", but is an instance of a constructor that does, or something |
| 13:03 | <asmodai> | mmm, Windows 7's math input panel generates a lot of unnecessary mrow's in their mathml output |
| 15:33 | <hsivonen> | Remember to object, folks: http://www.w3.org/2002/09/wbs/40318/issue-56-objection-poll/ |
| 16:11 | <TabAtkins> | hsivonen: I don't understand the implications of any of the options in that poll. |
| 16:13 | <hsivonen> | TabAtkins: well, at least IRIBIS has failed to deliver |
| 16:13 | <hsivonen> | TabAtkins: as mentioned in my Objection, Larry's Proposal is already over a year old! |
| 16:59 | <jgraham> | TabAtkins: Isn't the security concern with drawWindow not just cross-origin stuff? |
| 16:59 | <TabAtkins> | I... wouldn't think so? |
| 16:59 | <jgraham> | The comment emoller quoted suggests it is |
| 17:00 | <jgraham> | "endering the user's theme and then extracting the results |
| 17:00 | <jgraham> | +r |
| 17:00 | <jgraham> | rendering native anonymous content (e.g., file input paths" |
| 17:00 | <TabAtkins> | Darn, I skimmed past that part. |
| 17:01 | <TabAtkins> | I doubt that the user's theme is security-conscious, though I wouldn't be surprised if I was wrong. |
| 17:01 | <TabAtkins> | File inputs are a bit more important. |
| 17:01 | <hober> | hsivonen: your objection should really apply to both the first and second proposals |
| 17:01 | <TabAtkins> | We can render those specially as blank inputs, I guess? |
| 17:01 | <TabAtkins> | Or just punch holes in the canvas there. |
| 17:02 | <hober> | hsivonen: since the second proposal relies on the IRIbis folks providing a spec that adheres to the interface described in the proposal |
| 17:02 | <hsivonen> | hober: might be worthwhile to point that out on the poll |
| 17:03 | <smaug____> | user theme is not security, but possible privacy issue |
| 17:05 | <jgraham> | Is the security concern about reading colours from non-standard themes to make fake popups and so on look more convincing? |
| 17:05 | <jgraham> | (that doesn't seem like a very strong concern, but maybe I am wrong) |
| 17:06 | <smaug____> | ah, indeed, that would make it a some kind of security issue |
| 17:06 | <hober> | hsivonen: here's the current IRIbis text about "href" values: http://tools.ietf.org/html/draft-ietf-iri-3987bis-03#section-7.2 |
| 17:07 | <hober> | hsivonen: would you agree that it doesn't meet the needs of hixie's CP? |
| 17:07 | <Philip`> | drawWindow would have to hide visited link colours too |
| 17:07 | <hober> | hsivonen: I'm writing up my poll reply now actually :) |
| 17:08 | <hsivonen> | hober: sorry. I have to step away from the computer and can't review right now. |
| 17:08 | <hober> | hsivonen: fair enough |
| 19:12 | <AryehGregor> | annevk, are browsers planning to drop of CDATASection? Are there bugs filed and such? I don't see a Gecko bug. |
| 19:13 | <AryehGregor> | If there are no plans to act on it, I don't think the spec should claim this change is true. |
| 19:13 | <AryehGregor> | Where was this discussed, and who supported it? |
| 19:14 | Ms2ger | notes that cdata sections in HTML turn into Text nodes |
| 19:15 | <annevk> | the spec has a few such things without bugs |
| 19:15 | <annevk> | it's both ideas and reality |
| 19:15 | <annevk> | somewhat of a mixed bag |
| 19:15 | <annevk> | anyway, it's my time off now :) |
| 19:18 | <Ms2ger> | I'd do it, but our XML parser hurts my eyes |
| 19:21 | <AryehGregor> | Surely it's better than the HTML parser. |
| 19:22 | <Ms2ger> | Nope |
| 19:28 | <smaug____> | Ms2ger: ? |
| 19:29 | <smaug____> | Gecko's XML parser is expat |
| 19:29 | <smaug____> | is that really bad? |
| 19:29 | <zewt> | i don't know if it's good or bad, but it's certainly very common... |
| 19:30 | <Ms2ger> | You can judge it for yourself, but I think I'm going to stay away :) |
| 19:32 | <zewt> | i try to stay away from xml in general :) |
| 21:00 | <AryehGregor> | Could anyone explain to me why <view-source:http://test.wikipedia.org/wiki/Special:RecentChanges>; is not well-formed? My XML library claims there's a mismatched tag, but I just can't see it at the claimed position. |
| 21:02 | <AryehGregor> | Oh, wait. |
| 21:02 | <AryehGregor> | <br>. |
| 21:02 | <AryehGregor> | Huh. |
| 21:02 | <AryehGregor> | Okay, never mind. |
| 21:02 | <Philip`> | <br><span style="color: #999999;"><b>TEST WIKI</b></span></div> |
| 21:03 | <Philip`> | Oh, too late |
| 21:03 | <AryehGregor> | Yeah, I just mentally skipped over the <br>. |
| 21:03 | <AryehGregor> | It would help if my library told me where the bad opening tag was. |
| 21:03 | <AryehGregor> | (Python's xml.sax in this case) |
| 21:03 | <Philip`> | xmllint says "parser error : Opening and ending tag mismatch: br line 62 and div" |
| 21:05 | <AryehGregor> | That's more helpful. |
| 21:09 | <AryehGregor> | Okay, well, the well-formedness error isn't $wgHtml5's fault, so I don't have to fix it. |
| 21:09 | <AryehGregor> | Now we're ready for try three of Wikipedia on HTML5! |
| 21:09 | <AryehGregor> | Whenever a sysadmin gets around to it, anyway. |
| 21:20 | <TabAtkins> | Man, <xmp> really does make my examples way easier to read. I'll have to take it out eventually due to pubrules, but it's so nice to use it in my editor's drafts. |
| 21:26 | <jamesr> | AryehGregor: no more xhtml? |
| 21:27 | <AryehGregor> | jamesr, <!DOCTYPE html> is the plan. But we'll still output well-formed XML, because of all the screen-scraping bots that depend on it. |
| 21:27 | <AryehGregor> | Including browser-based stuff using XHR responseXML or whatever it's called, who can't easily switch to a non-XML parser. |
| 21:28 | <jamesr> | AryehGregor: heh - that would actually make wikipedia load a lot faster in webkit because we currently don't prefetch for anything that we parse with the XML parser but we do prefetch stuff that uses the HTML parser |
| 21:28 | <AryehGregor> | jamesr, we've always been serving as text/html. |
| 21:28 | <AryehGregor> | Serving with an XML MIME type would be insane. |
| 21:28 | <AryehGregor> | For all sorts of reasons. |
| 21:28 | <jamesr> | yeah but we for some reason use the XML parser, iirc |
| 21:28 | <AryehGregor> | Seriously? |
| 21:28 | <AryehGregor> | That sounds incredibly unlikely. |
| 21:29 | <AryehGregor> | It violates the HTML5 spec, and it also would break some pages. |
| 21:29 | <AryehGregor> | Because we don't output well-formed XML 100% of the time, there are known bugs. |
| 21:29 | <AryehGregor> | Like: http://test.wikipedia.org/wiki/Special:RecentChanges |
| 21:29 | <jamesr> | it's an XML doctype, hmmm |
| 21:29 | <AryehGregor> | Yes, but no browser actually parses as XML if there's an XML doctype present. |
| 21:29 | <AryehGregor> | Loads of pages have XML doctypes but are horribly malformed. |
| 21:30 | <jamesr> | time for gdb |
| 21:30 | <AryehGregor> | Just observe that you can load http://test.wikipedia.org/wiki/Special:RecentChanges in WebKit and don't get a YSOD. |
| 21:30 | <AryehGregor> | But it's malformed. |
| 21:30 | <AryehGregor> | (<br> instead of <br />) |
| 22:06 | <AryehGregor> | "Compared to CSS, tables take more bandwidth, they aren't as cacheable, they require you to cut images, they result in pages that aren't as maintainable, and aren't rendered incrementally in many browsers." |
| 22:06 | <AryehGregor> | What browsers don't render tables incrementally? |
| 22:06 | <Philip`> | Netscape 4? |
| 22:06 | <AryehGregor> | Or does it just mean that they do a two-pass layout and jump as the page loads? |
| 22:07 | <AryehGregor> | Okay, does Netscape 4 count as "many"? |
| 22:07 | Philip` | was just guessing about Netscape |
| 22:10 | <AryehGregor> | Personally, I think the chairs made the right decision in ISSUE-130. |
| 22:10 | <AryehGregor> | Hurrah for <table role=presentation>. |
| 22:17 | AryehGregor | makes a mental note to add role= support to MediaWiki |
| 22:51 | <Hixie> | hey does anyone know what "valid" means here? the definition makes no sense to me: |
| 22:51 | <Hixie> | http://dev.w3.org/2006/webapi/FileAPI/#valid |
| 23:14 | hober | reads |
| 23:14 | <hober> | yeah, that doesn't make sense |
| 23:15 | <hober> | ObPollReminder: http://www.w3.org/2002/09/wbs/40318/issue-127-objection-poll/ closes today |
| 23:35 | <Hixie> | TabAtkins: is there a css property for making an image be a reflection of itself? transform(mirror) or something? |
| 23:35 | <Hixie> | doesn't have to be implemented yet |
| 23:37 | <Hixie> | hm, you can give a matrix |
| 23:37 | <Hixie> | and iirc there's a matrix that'll reflect |
| 23:37 | <Hixie> | -1 0, 0 1? |
| 23:38 | <Hixie> | or scaleX(-1) |
| 23:39 | <Hixie> | aha! |
| 23:39 | <Hixie> | yes! |
| 23:39 | <zewt> | <TabAtkins> np |
| 23:54 | <Hixie> | heycam: so i'm doing the video conferencing stuff and i need to expose the current list of streams |
| 23:54 | <Hixie> | heycam: that's an array/list/set/whatever of Stream objects |
| 23:54 | <Hixie> | heycam: what's the best way of exposing that to the page? I don't mind if it's a live list |
| 23:54 | <Hixie> | or not |
