| 03:44 | <Lachy> | hey, anyone in here have any idea about topics I should try to cover in a panel about the state of the web as a platform? So far I have web storage/database, appcache, workers, video/audio, canvas. |
| 03:47 | <Lachy> | the panel is a discussion between browser vendor reps, adobe flash and W3C, talking about the web as a platform. Though, it's in the business track, so it has a business focuss rather than an overly technical focus |
| 04:19 | <MikeSmith> | Lachy: Web Sockets |
| 07:50 | <othermaciej> | the HTML5 editor's draft is now in my Top Sites in Safari |
| 07:51 | <othermaciej> | I guess I should only be surprised that it wasn't before |
| 08:49 | jgraham | wonders if Philip` has enough data to determine if detecting the encoding from the XML prolog is needed |
| 09:03 | <Philip`> | jgraham: Seems hard to analyse - I can't just autodetect the charset and then compare against the correct charset, because the only way I can determine the correct charset is by guessing based on the autodetection |
| 09:05 | <gsnedders> | Philip`: Number of errors when decoding? |
| 09:05 | <jgraham> | Philip`: Yeah I know it's not easy. Perhaps just find pages for which the XML prolog makes a difference and then manually decide if they are better or worse with the XML prolog charset |
| 09:06 | <jgraham> | gsnedders: It doesn't seem like the differences would neccesarily be errors though? |
| 09:06 | <gsnedders> | jgraham: Right, I know, it's a limitation, but I can't see any better way to do it withoiut manual inspection of every file |
| 09:07 | <jgraham> | gsnedders: Right but there might only be a handful of files where it makes a difference |
| 09:07 | <jgraham> | If there's not just inspecting the first few should give an idea if it makes it better or worse |
| 09:08 | <Philip`> | gsnedders: Number of errors doesn't help when the default fallback is Win1252 and everything decodes with zero errors |
| 09:09 | <gsnedders> | Philip`: If the other encoding also decodes with zero errors? I know that it will always decode with zero with the fallback. |
| 09:10 | Philip` | doesn't even know whether he's currently decoding pages correctly using the current algorithm, and doesn't know an easy way to test it |
| 09:10 | <Philip`> | (I think I attempt to put the content-type charset into some stream object and then let the validator.nu parser sort it out, or something, but it seems to go wrong in a lot of cases) |
| 10:17 | <smaug> | Hixie: do you have plans to fix history session in HTML5? I'll propose something if I figure out how I'd like it to work. |
| 10:18 | <Hixie> | i wasn't aware that it was broken |
| 10:18 | <Hixie> | if it's broken, then i plan to fix it |
| 10:19 | <smaug> | Hixie: I sent an email about it |
| 10:19 | <Hixie> | ah then i have plans to read and respond to your e-mail, yes |
| 10:19 | <Hixie> | it'll be in my queue somewhere |
| 10:20 | <Hixie> | is it urgent? |
| 10:20 | <smaug> | it doesn't explain how iframe history works in previous top level pages |
| 10:20 | <Hixie> | (i plan to basically respond to all outstanding bugs and e-mails by the end of the month) |
| 10:20 | <smaug> | well, I'd like to implement it, like now :) |
| 10:21 | <Hixie> | ah ok |
| 10:21 | <Hixie> | let me see if i can give you a preliminary answer |
| 10:24 | <Hixie> | do you know if there are compatibility concerns here? |
| 10:25 | <Hixie> | looks like IE8 does what the spec says right? |
| 10:26 | <smaug> | browsers implement go() in different ways, so perhaps no compatibility concerns |
| 10:26 | <smaug> | IE8 is quite close |
| 10:26 | <smaug> | those its back button doesn't map to go() handling. Maybe that is UA dependent thing |
| 10:27 | <smaug> | s/those/though/ |
| 10:28 | <smaug> | Hixie: still, what in the spec explains that the previous top level page should load latest iframe document? |
| 10:29 | <roc> | dammit |
| 10:29 | <smaug> | the draft doesn't really say anything about what should happen to sub-browsing contexts when previous top level page is loaded |
| 10:30 | <roc> | I thought I found an ambiguity in the spec, but I was wrong |
| 10:30 | <Hixie> | what IE8 does seems to have security advantages, though it does mean that for go(x) where |x| > 1 the back button doesn't match the API |
| 10:30 | <Hixie> | dunno if that's a problem |
| 10:31 | <Hixie> | smaug: hold on, minor cat emergency |
| 10:33 | <roc> | is it documented what the owner document is for an element created with "new Audio()"? |
| 10:36 | <zcorpan_> | roc: what happens for new Image()? |
| 10:36 | <roc> | no idea |
| 10:37 | <roc> | I *assume* that you use the document of the current global object, which must be a Window |
| 10:37 | <roc> | I'm not JS-savvy enough to know if you can get into a situation where there is no Window in scope |
| 10:38 | <roc> | but the spec doesn't seem to say, or if it does, I don't know where |
| 10:38 | <othermaciej> | the spec doesn't say what the owner document should be (very clearly) |
| 10:39 | <othermaciej> | it should say invoking the Audio constructor is equivalent to document.createElement() followed by setting some attributes |
| 10:39 | <othermaciej> | or something like that |
| 10:39 | <roc> | it can't say that since 'document' might refer to something strange |
| 10:40 | zcorpan_ | files a bug |
| 10:40 | <smaug> | roc: yeah, at least gecko finds the document from caller and uses that as owner document |
| 10:42 | <Hixie> | smaug: ok back |
| 10:43 | <Hixie> | smaug: assuming we do go with the IE8 model, then a literal reading of the spec would mean that when you go back, you just end up in whatever state you happened to last be when that top-level browsing context last had that document active |
| 10:43 | <Hixie> | smaug: which means that if you were to go to A-2, then fast-forward to B-2, then go(-2), you should end up at A-2 again |
| 10:44 | <Hixie> | smaug: even though going go(+1) from there would take you to A-3 |
| 10:44 | <Hixie> | smaug: and then going go(+1) again would take you to B-2, not B-1 |
| 10:44 | <roc> | smaug: do you happen to know what happens if we call new Audio in a context where there is no document? like say a JS XPCOM component? (this is obviously beyond the realm of HTML5) |
| 10:44 | <Hixie> | i guess we should see what IE does with those cases |
| 10:44 | <smaug> | roc: I don't think that is supported |
| 10:45 | <roc> | ok, but what happens? :-) |
| 10:45 | <smaug> | roc: calling the constructor fails |
| 10:45 | <Hixie> | smaug: can you stick a javascript:go(-2) and a javascript:go(+1) to A-2, A-3, B-1, and B-2? |
| 10:45 | <roc> | ok |
| 10:46 | smaug | boots a windows machine |
| 10:46 | <Hixie> | woo, IE8 does do what i said for the first thing i described |
| 10:46 | <Hixie> | the go(-2) case where you navigated the history as i described |
| 10:47 | <Hixie> | and then clicking forward from A-2 goes to A-3, and from there goes to B-2 |
| 10:47 | <Hixie> | and clicking back there goes to B-1 |
| 10:47 | <Hixie> | not saying that's the most understandable UI |
| 10:47 | <Hixie> | but it does match what I'd expect the API to do per the spec |
| 10:47 | <smaug> | Hixie: but the go(-3) goes to the startpage in my testcase |
| 10:48 | <Hixie> | right, it would |
| 10:48 | <Hixie> | because the subframes aren't in the joint history |
| 10:48 | <Hixie> | the subframes of the inactive documents, i mean |
| 10:48 | <smaug> | and still, where does the draft say what the iframes should load when going back in top level page? |
| 10:49 | <Hixie> | well there are two possible cases: |
| 10:49 | <Hixie> | 1. bfcache is active, doc is in the cache: you just show it as it was, unchanged |
| 10:49 | <smaug> | that is easy |
| 10:49 | <smaug> | that is why I disable bfcache |
| 10:49 | <smaug> | at least for gecko |
| 10:49 | <smaug> | but without bfcache |
| 10:50 | <smaug> | (btw, do all the browsers have something like? maybe chrome doesn't, at least its back-forward is slower than in other browsers) |
| 10:51 | <Hixie> | 2. doc was evicted from bfcache, and you have to refetch the document and rerender it and so forth: the iframes are considered "persisted user state" which the UA is allowed to resync |
| 10:51 | <Hixie> | i should probably spec that in more detail |
| 10:52 | <smaug> | and how can the browser know which iframe loads which page? |
| 10:52 | <Hixie> | beats me |
| 10:52 | <Hixie> | how does firefox do it? |
| 10:52 | <Hixie> | the most obvious solution is to serialise the state of each frame's frames[] hierarchy |
| 10:53 | <smaug> | gecko has a tree of browsing contexts |
| 10:53 | <smaug> | or tree of session histories |
| 10:53 | <Hixie> | and just walk down the tree as each one onloads, navigating its subframes accordingly |
| 10:53 | <Hixie> | but how does it map them to iframes? |
| 10:53 | <smaug> | but the way it is implemented doesn't work well with dynamic iframe additions/removals |
| 10:54 | <smaug> | it tries to map session history tree to browsing context tree |
| 10:54 | <smaug> | and with dynamic iframe additions/removals that isn't always right |
| 10:54 | <smaug> | ...and that is what I'm trying to fix |
| 10:55 | <smaug> | but I'd like to fix it to do something which is actually spec'ed somewhere |
| 10:55 | <Hixie> | what do other UAs do? |
| 10:56 | <smaug> | not sure. |
| 10:56 | <smaug> | well, webkit's go() handling is already so strange that it is difficult to test |
| 10:58 | <smaug> | but as a starting point I'd like to understand how go() should work |
| 10:58 | <smaug> | and then figure out what to do with dynamic changes |
| 10:59 | <Hixie> | well the spec doesn't really say what to do with iframes when reloading a document evicted from the bfcache (or never stored in the first place) |
| 10:59 | <Hixie> | i'm more or less happy to spec anything you come up with, if it's sane and/or matches implementations and/or legacy content expectations |
| 11:00 | <smaug> | ok, I'll continue testing |
| 11:00 | <Hixie> | for things in the bfcache, it seems the spec matches IE8, which is good |
| 11:00 | <Hixie> | so i'd like to standardise on that |
| 11:01 | <Hixie> | it seems to make sense and is relatively easy to describe |
| 11:01 | <smaug> | yeah, I haven't seen anything in IE8's behavior that I'm against at. (except its back button functionality) |
| 11:02 | <Hixie> | well the back button and the go() API don't have to match, so you're welcome to make that work however you like |
| 11:03 | <smaug> | does anyone know how to disable bfcache in IE? Would unload handler be enough? |
| 11:21 | <zcorpan_> | i wonder what i'm doing wrong with getting a webkit nightly to run with safari on windows |
| 11:22 | <zcorpan_> | run-nightly-webkit.cmd doesn't do anything, and FindSafari.exe gives an error message saying some configuration is wrong |
| 11:22 | <annevk2> | did you run the install script? |
| 11:22 | annevk2 | remembers some exe file |
| 11:22 | <annevk2> | oh, dunno then |
| 11:25 | <zcorpan_> | if i paste the contents of the extracted folder into the Safari folder and replace the files, then FindSafari.exe and run-nightly-webkit.cmd still do the same thing and Safari.exe stops working |
| 11:26 | <annevk2> | nuke all and start over? |
| 11:26 | <zcorpan_> | still same result |
| 11:26 | <annevk2> | ask in #webkit? |
| 11:26 | <zcorpan_> | k |
| 11:43 | <hsivonen> | another nail in the coffin of conneg: https://twitter.com/glazou/statuses/4705685278 |
| 11:47 | <gsnedders> | Single language keywords in indexes pose a problem for HTTP conneg? |
| 11:48 | <gsnedders> | Or am I proving I'm half-asleep at the moment, under the theory I can't do any language when half asleep? |
| 11:48 | <hsivonen> | crawlers presumably index only one of the language alternatives |
| 11:48 | <gsnedders> | Ah, that sort of index |
| 11:48 | <gsnedders> | I was thinking of the sort of index that CSS 2.1 has of various terms |
| 11:48 | <gsnedders> | (which has no problems with conneg) |
| 11:49 | <hsivonen> | the kind of conneg that works is gzip conneg. |
| 11:49 | <hsivonen> | which arguably is an architectural error |
| 11:49 | <hsivonen> | shoud be a characteristic of the HTTP hop--not the representation |
| 11:50 | <hsivonen> | should |
| 11:51 | <jgraham> | HTTP hop? |
| 11:51 | <gsnedders> | A hop and a jump, obviously. |
| 11:51 | <hsivonen> | jgraham: origin server to intermediary or intermediary to intermediary or intermediary to client |
| 11:52 | <jgraham> | Hmm I don't clearly see what alternative you are proposing |
| 11:53 | <jgraham> | (for some definition of proposing which means "not proposing but suggesting might have been better in the first place") |
| 11:54 | <hsivonen> | jgraham: Transfer-Encoding |
| 11:54 | <jgraham> | Ah |
| 11:54 | <gsnedders> | (Quick! Music suggestions!) |
| 11:56 | <jgraham> | The minute waltz is quite a quick piece of music |
| 12:45 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#attributes-0 |
| 12:45 | <Hixie> | doesn't include global attributes |
| 12:45 | <Hixie> | file bugs with problems! |
| 12:45 | <Hixie> | bed time now |
| 12:45 | <Hixie> | nn |
| 12:54 | annevk2 | still wonders whether this is generated or not |
| 12:55 | <annevk2> | default value might be nice (i.e. what happens if omitted) |
| 13:12 | <hsivonen> | are chaals' parisweb slides available online yet? |
| 13:14 | <Philip`> | hsivonen: Hop-based compression sounds bad for deployability, since to add a new compression method you need everybody on your HTTP path to support it, rather than just getting servers and clients to cooperate |
| 13:16 | <Philip`> | But I suppose it's necessary in order to get sane behaviour from proxies |
| 13:17 | <Philip`> | (particularly with partial downloads etc) |
| 13:19 | <hsivonen> | Philip`: no, with per-hop compression, you get benefits even if one hop is compressed |
| 13:37 | <zcorpan_> | hsivonen: woah, i was completely unaware of createHTMLDocument |
| 13:45 | <hsivonen> | zcorpan_: it's a bit scary how the functionality has been discussed here before and people have appeared to be unaware |
| 13:45 | <hsivonen> | (I was unaware until today) |
| 14:12 | <othermaciej> | wait, is createHTMLDocument a real public method? cause when we were discussing it the other day I saw it in the WebKit source and I assumed it was an extension of some kind |
| 14:12 | <othermaciej> | ah, HTMLDOMImplementation |
| 14:13 | <hsivonen> | othermaciej: it seems it's a real public method that was axed from specs between DOM Level 2 HTML CR and REC |
| 14:13 | <othermaciej> | I see |
| 14:14 | <othermaciej> | WebKit's IDL claims it is real but I didn't see it in the spec |
| 14:14 | <othermaciej> | HTML5 should spec it IMO |
| 14:14 | <Philip`> | "... our first Last Call ... a second Last Call ..." - this must be a new meaning of 'last' with which I was previously unfamiliar |
| 14:15 | <othermaciej> | Philip`: W3C Process makes it highly unlikely that a large spec of wide interest could have just one |
| 14:16 | <Philip`> | The process seems sensible, it's just that the naming doesn't quite :-) |
| 14:16 | <othermaciej> | we can rename it Awesome Call if you'd like |
| 14:17 | <othermaciej> | what browsers support createHTMLDocument? |
| 14:17 | <hsivonen> | othermaciej: Opera and WebKit have it (as non-undefined) |
| 14:17 | <hsivonen> | othermaciej: undefined in Gecko |
| 14:18 | <hsivonen> | othermaciej: didn't test IE |
| 14:18 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/266 |
| 14:20 | <othermaciej> | damn, I was halfway through filing a bug on createHTMLDocument when I remembered that I should follow what I said about what goes in a bug report |
| 14:20 | <gsnedders> | othermaciej: I'd say it should be in Web DOM Core |
| 14:20 | <gsnedders> | But nobody's working on that, so that's mainly a theoretical concern |
| 14:20 | <annevk2> | it seems very HTML-specific |
| 14:20 | <othermaciej> | gsnedders: it was originally a DOM2HTML method... I could see the argument either way I suppose |
| 14:21 | <annevk2> | so if you don't want a normative dependency on DOM Core putting it in HTML5 makes sense |
| 14:21 | <gsnedders> | We're going to end up with HTML specific stuff in DOM Core if we want to avoid having HTML 5 contradicting DOM Core |
| 14:21 | <gsnedders> | (See IRC logs from yesterday) |
| 14:24 | <othermaciej> | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=7842 |
| 14:24 | <othermaciej> | feel free to add comments if you think it should go in Web DOM Core instead |
| 14:25 | <othermaciej> | I would feel better about that approach if Web DOM Core was under active development |
| 14:26 | <gsnedders> | Right, as Web DOM Core isn't, I don't feel very strongly eitehr way |
| 14:29 | jgraham | would generally feel better if WDC was under active development |
| 14:31 | <annevk2> | now and then I'm somewhat tempted to pick it up, but I already dropped the ball on CSSOM and hardly have time |
| 14:33 | <othermaciej> | oops, didn't see the whatwg email, I guess my bug is somewhat redundant |
| 14:35 | <jgraham> | Yeah now and then I'm somewhat tempted to pick it up but I guess I don't need more to (not) do at the weekend |
| 14:40 | <othermaciej> | speaking of specs in need of editing action, Web IDL might need a co-editor, given the time pressure due to dependencies and the fact that heycam has been super busy for a while |
| 14:40 | <hsivonen> | hmm. am I testing wrong or does IE8 not even have createDocument? |
| 14:40 | <othermaciej> | unlike Web DOM Core and CSSOM, that could block things from progressing |
| 14:41 | <zcorpan_> | hsivonen: i think ie8 doesn't have createDocument |
| 14:43 | <hsivonen> | at times I'm surprised how wide the IE and everything else chasm is, even though I should know better not to be surprised anymore |
| 14:43 | <othermaciej> | in a way, it's because IE did too well at Browser War 1.0 |
| 14:44 | <othermaciej> | they embraced and extended so far, that it was way easier to clone Mozilla's behavior than theirs |
| 14:45 | <TabAtkins> | Worse Is Better, essentially? |
| 14:45 | <othermaciej> | I don't know if it was fair to say Gecko was "Worse" than Trident |
| 14:46 | <hsivonen> | part of the story is that the de jure specs were notable different from both IE and Netscape 4 |
| 14:46 | <othermaciej> | it just had fewer inexplicably complex quirks, fewer super complex proprietary technologies that you have to implement to work with their code path, and source you can look at |
| 14:47 | <hsivonen> | and Mozilla went pretty far following the de jure specs instead of getting the specs changed to match what was out there already |
| 14:47 | <othermaciej> | basically there were a lot of cases where we could have chosen to implement IE behavior instead of Mozilla behavior in WebKit, but only if we were also willing to implement ActiveX, VBScript, VML... |
| 14:47 | <othermaciej> | that is true as well - having the specs on your side helps with evangelism I guess |
| 14:48 | <hsivonen> | in retrospect, I wish the idea of changing the specs to match reality had been discovered early enough to avoid the Almost Standards Mode and <p><table> |
| 14:48 | <jgraham> | The size of this gap seems to create a problem for the spec now as people occasionally try to throw an idea right down the middle of the chasm |
| 14:49 | <othermaciej> | but our early strategy for Safari was much more "copy Gecko" than "follow standards", and largely because IE successfully made it really hard to copy them |
| 14:49 | <jgraham> | On the basis that anything closer to the WebKit Gecko Presto side wouldn't be implementable in IE |
| 14:49 | <jgraham> | But you end up with something that is implementable in nheither |
| 14:49 | <jgraham> | *neither |
| 14:50 | <zcorpan_> | hsivonen: and standards mode |
| 14:50 | <hsivonen> | zcorpan_: that, too |
| 14:51 | hsivonen | sees no value in toggling unitless number parsing behavior and class case-sensitivity |
| 14:54 | <othermaciej> | some standards mode changes seem gratuitous |
| 14:54 | <othermaciej> | but some quirks mode quirks are pretty messed up |
| 14:55 | <othermaciej> | I can understand the temptation to get away from all that |
| 14:55 | <hsivonen> | not inheriting to tables is messed up |
| 14:55 | <hsivonen> | but having to write table { quirks: none; } would probably be a better switch that the doctype |
| 14:55 | <hsivonen> | *than |
| 14:56 | <othermaciej> | true |
| 14:56 | <othermaciej> | one of the annoying things about quirks mode is that it switches so many different things |
| 14:57 | <annevk2> | fortunately we can make it a fixed list when we realize what all the quirks are and never extend them |
| 14:58 | <zcorpan_> | ...other than for having things consistent in the quirks mode (e.g. getElementsByClassName and case-sensitivity) |
| 15:05 | <annevk2> | true :/ |
| 15:05 | <annevk2> | though classList is not consistent |
| 15:06 | <annevk2> | it would prolly have made more sense to define that classes are always interned to lowercase in quirks mode and that comparisons are case-sensitive |
| 15:06 | <annevk2> | but that requires changes to CSS too |
| 15:07 | <TabAtkins> | Anyone who uses uppercase in their classes is a weirdo anyway. |
| 15:08 | <jgraham> | class=ImSaneAndHaveACertificateToProveIt |
| 15:16 | <hsivonen> | Either I've broken the parser or the AOL front page has an *insane* number of <script> elements |
| 15:22 | <hsivonen> | wow. looks like CNN latest news list has a script per line or something like that |
| 15:24 | <lmorchard> | Rendering that timestamp just so is a job best left to the client, apparently |
| 15:27 | <hsivonen> | the good news is that even though both AOL and CNN have a large number of scripts on the front page, they don't document.write() unbalanced trees |
| 15:27 | <hsivonen> | all speculations seem to succeed |
| 16:17 | <TabAtkins> | What's a decent feature-test for <details> support? |
| 16:22 | <jgraham> | details.open !== undefined |
| 16:24 | <TabAtkins> | See, that's what I thought, but it's throwing a "details is not defined" error in FF. |
| 16:25 | <jgraham> | you did var details = document.getElementsByTagName("details")[0]? |
| 16:25 | <TabAtkins> | Of course not, because I am dumb. |
| 16:25 | <jgraham> | var details = document.createElement("details") |
| 16:26 | <jgraham> | +or |
| 16:27 | <TabAtkins> | All right, works. :facepalm: |
| 16:43 | <TabAtkins> | Yay for tantek's "A Study of Regular Polygons". Now my details support is complete without using any images. |
| 17:03 | <TabAtkins> | Hey, Tantek, I just (about half an hour ago) made good use of your regular polygons while implementing details support. Thanks. ^_^ |
| 17:04 | <TabAtkins> | (Used it on detail>dt::before for the toggler arrow.) |
| 17:43 | <gsnedders> | Why does javascript:alert(document.createElement("iframe").contentDocument) output null/undefined? Because the iframe hasn't loaded yet? Shouldn't it default to about:blank? |
| 17:51 | <gsnedders> | Hmm, needs to be added to the document to render |
| 17:52 | <gsnedders> | s/to render/to not be null/ |
| 17:52 | <gsnedders> | Even if a child of head, for example |
| 17:52 | <gsnedders> | Odd |
| 17:57 | <gsnedders> | Oh, even odder. In Opera, if it is in a script before <body> then it is always null. |
| 17:57 | <annevk42> | what does HTML5 say? |
| 17:57 | <gsnedders> | If it (the script) is after body it works even if the iframe is put in head |
| 17:58 | <gsnedders> | annevk42: I've been looking, and I'm not quite sure. As far as I can tell it says that it should never return null and always the document |
| 18:00 | <gsnedders> | (If someone could confirm whether I'm right/wrong about HTML 5 it'd be nice) |
| 18:35 | annevk42 | looks |
| 18:48 | <tantek> | TabAtkins - good to hear! Do you have a URL to share? |
| 21:20 | <TabAtkins> | tantek: You want a permanent url, or is a temporary good enough? The actual usage is on an intranet app that's behind a password, but I can either turn off the password temporarily, or just duplicate the page entirely. |
| 21:21 | <tantek> | I'd say better to duplicate (perhaps a simplified version) of the page to keep public as part of your portfolio |
| 21:21 | <tantek> | so others can benefit from the techniques as wwell |
| 21:21 | <TabAtkins> | k, one moment. |
| 21:24 | <TabAtkins> | tantek: http://www.xanthir.com/etc/details/ |
| 21:25 | <tantek> | nice! |
| 21:28 | <TabAtkins> | It works in IE8, but not very smoothly. Dunno why. |
| 21:30 | <TabAtkins> | That reminds me, there are a few other clever tricks I've been meaning to show off that are locked behind intranet pages here at work. I'll get a few of those uploaded today. |
| 21:37 | <TabAtkins> | tantek: Frex, here's me putting the "hidden radio buttons" trick to work to simplify a giant list - http://www.xanthir.com/etc/hidden-radios/ |
| 22:06 | <daedb> | TabAtkins: that's a neat trick :) |
| 22:06 | <TabAtkins> | Can't take full credit - I learned it from Brad Kemper. But I do think the use I put it to is pretty clever. ^_^ |
| 22:30 | <Hixie> | annevk2: no, it's all manually generated |