| 00:00 | gsnedders | wonders if it does anything |
| 00:00 | <zewt> | it should warn if you *don't* have typos |
| 00:02 | <gsnedders> | Okay, it doesn't do anything. |
| 00:02 | <zewt> | seems strange that browsers still don't allow copying out of password fields |
| 00:02 | <zewt> | even though every browser lets you get at it in inspector tools anyway |
| 00:10 | <Hixie> | WeirdAl: they keep fricking changing and keeping them up to date is of no value to me whatsoever |
| 00:11 | <WeirdAl> | I'll admit, it probably looks good on a thousand resumes. |
| 00:11 | <WeirdAl> | but other than that... |
| 00:13 | <Hixie> | not the acknowledgements, i mean the references section |
| 00:13 | <WeirdAl> | oh |
| 00:13 | <Hixie> | certainly not going to remove the names from the acknowledgements section, listing those names is the least i can do given how much help everyone has been |
| 00:16 | <Hixie> | annevk: btw i checked and i'm still sending your script the "typo"/"xref" thing, even when i'm sending the svn repo and e-mails a longer description |
| 06:03 | <hsivonen> | hober: The OAuth story really calls for "if you take your spec to the IETF, you're going to have a bad time", despite the frequency of the appearance of the super-cool ski instructor. |
| 06:04 | <hsivonen> | hober: I guess that the reason why the super-cool ski instructor appears so frequently is that it's the only advice animal that actually gives advice, and advice is needed when making standards. |
| 06:14 | <roc> | I believe the Opus IETF group wasn't terrible |
| 06:20 | <tantek> | that's good to hear |
| 06:24 | <annevk> | Hixie: cool |
| 06:24 | <annevk> | hober: my meme suggestion was a bad one |
| 06:45 | <annevk> | http://www.karlgroves.com/2012/07/26/selling-accessibility-negative-factors/ this is pretty how much how accessibility topics are handled in a F2F |
| 06:48 | <tantek> | annevk - wow |
| 06:48 | <tantek> | "The fact that accessibility is so hard and time consuming is partly because accessibility folks spend a lot of time chasing unicorns – seeking to pile on new requirements, check-points, and validation plans in hopes to make everything perfect. They separate instead of integrate and only show up when it is time to tell people they’ve messed everything up." |
| 06:48 | <annevk> | also the bit about hostility and FUD |
| 06:49 | <annevk> | every time I meet John Foliot he mentions lawsuits, rules of large corporations, new US legislation |
| 06:50 | <annevk> | not very compelling |
| 07:16 | <matjas> | zewt: re: astral symbols in <input type=password>, is it a bug to show them as two symbols or not? I’m not sure, with DOM strings being UTF-16 and all |
| 07:30 | <annevk> | matjas: depends on the UI requirements |
| 07:30 | <annevk> | matjas: it seems like suboptimal UI, but not necessarily a bug |
| 07:31 | <matjas> | annevk: is this stuff in a spec somewhere? |
| 07:31 | <annevk> | matjas: we don't spec UI |
| 07:31 | <hsivonen> | it seems like a bug but not one that's important to fix |
| 07:31 | <annevk> | matjas: you could take a look if the Rendering section says something, but I doubt it |
| 07:32 | <annevk> | "When the input-password binding applies, to an input element whose type attribute is in the Password state, the element is expected to render as an 'inline-block' box rendered as a text field whose contents are obscured." |
| 07:32 | <matjas> | that’s all I could find too |
| 07:33 | <kennyluck> | Hixie, you mentioned you were asking people about requirements on input mode control. Do you have a mail that summarizes your questions or something? |
| 07:33 | <hsivonen> | rendering two bullets for one character sure counts as obscured! |
| 07:33 | <annevk> | what I want fixed more than this is a "reveal password" thingie |
| 07:34 | <annevk> | kennyluck: we're look for use cases here: http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control |
| 07:35 | <kennyluck> | annevk, yeah, I know that page, though Hixie indicated that he sent some mails out, not sure if those were internal. |
| 07:35 | <kennyluck> | or I might have misinterpreted what he said. |
| 07:51 | <hsivonen> | MikeSmith: I think I should gather some stats about how validator.nu is used. Stuff like HTML5 versus HTML 4 usage numbers. |
| 07:51 | <MikeSmith> | yeah would be useful |
| 07:51 | <hsivonen> | MikeSmith: Any ideas what in particular I should measure? |
| 07:51 | <MikeSmith> | no particular ideas at the moment |
| 07:51 | <MikeSmith> | will try to think of some |
| 07:51 | <hsivonen> | MikeSmith: I'm not planning any fancy back end: just an object in RAM that can dump its data to a HTTP, so no disk I/O is needed. |
| 07:52 | <MikeSmith> | OK |
| 07:53 | <hsivonen> | My connectivity to Mozilla's important infrastructure is broken today, so I better take advantage of the validator hacking opportunity. |
| 07:53 | <MikeSmith> | hah |
| 07:53 | <MikeSmith> | yeah please do |
| 07:55 | <payman> | kennyluck: https://plus.google.com/107429617152575897589/posts/WwVmKNjcZ4p |
| 07:55 | <kennyluck> | payman, thanks! |
| 07:57 | <hsivonen> | MikeSmith: I think I should try to find out if people actually use custom Schematron |
| 08:01 | <annevk> | hsivonen: just measure all the settings? |
| 08:03 | <hsivonen> | annevk: it would be inappropriate to give a public dump of that |
| 08:03 | <hsivonen> | and I don't want to develop access-control |
| 08:03 | <annevk> | which would be wrong? |
| 08:03 | <hsivonen> | annevk: dumping the URLs of custom schemas |
| 08:05 | <annevk> | maybe you should hash them so you can at least count frequency? |
| 08:05 | <annevk> | but measuring first whether they're popular at all seems fine |
| 08:06 | tantek | just read that OAuth 2.0 and road to hell blog post and came upon Hixie's comment as well: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/#comment-42017 |
| 08:09 | <annevk> | uhuh |
| 08:09 | <annevk> | WebSocket :( |
| 08:09 | <annevk> | although it didn't turn out all bad |
| 08:12 | <tantek> | I knew things about IETF were quirky and odd (e.g. the humming), but I didn't realize it was that broken (and susceptible to enterprise hijacking). |
| 08:16 | <ashemedai> | So with MathML in HTML5, am I supposed to use ∫ or just use Unicode and put ∫ ? |
| 08:24 | <annevk> | up to you |
| 08:35 | <ashemedai> | annevk: Shouldn't cause any problems that you know of at least? I mean, semantically ∫ might be passing along some additional info, not sure how UAs deal with this. |
| 08:39 | <hsivonen> | ashemedai: ∫ doesn't pass any additional semantics |
| 08:41 | <ashemedai> | hsivonen: Brilliant, cheers. |
| 08:44 | <ashemedai> | Wonder if I should try compiling https://github.com/w3c/tidy-html5 under Windows one of these days. |
| 08:50 | <annevk> | ashemedai: the way it works is that ∫ ends up as ∫ in the tree |
| 08:51 | <annevk> | ashemedai: so it's purely a source text affair and the source text is not exposed |
| 08:56 | <Stevef_> | hsivonen: your focus outline proposal is a crowd pleaser - thanks for filing and ccing me |
| 08:56 | <ashemedai> | annevk: gotcha |
| 08:59 | <ashemedai> | Microsoft's Math Input Panel loves to add a lot of extra <mrow>s in places it need not to. |
| 09:06 | <ashemedai> | Heh, even in a function specification like f(u,v) it made , a <mo> |
| 09:08 | <ashemedai> | Quite interesting how MathML can show the same rendering with quite varied MathML constructs. |
| 09:21 | <odinho> | I like that accessibility blog post. |
| 09:23 | <jgraham> | I would like it more if my experience wasn't that certain people it praises do all the things it criticises |
| 09:24 | <odinho> | jgraham: lol, you may replace them with "foo" and "bar" whilst reading. |
| 09:28 | <ashemedai> | Oh hey |
| 09:28 | <ashemedai> | The Wikipedia code has been updated. That MathJax change is now live on the main servers. |
| 09:28 | <ashemedai> | When logged in, under Appearance in Preferences |
| 09:50 | <Stevef_> | jgraham: I think you mean a certain person and I think it is important to draw a distinction between how people act in particular contexts (work) or when ineteracting with particular communities |
| 09:57 | <jgraham> | Stevef_: Yes, one person. |
| 09:58 | <Stevef_> | jgraham: John foliot can be a very positive force in web standards and bringing together the different communities open web camp for example http://openwebcamp.org/ |
| 09:59 | <Stevef_> | jgraham: and like myself and many other people in the web standards community he can be disruptive at times |
| 10:01 | <hsivonen> | Stevef_: I filed the focus thing out of my personal need--not to please a crowd. I CCed you, because I mentioned it to you earlier. |
| 10:02 | <Stevef_> | hsivonen: fine, what i meant was it is a good idea and was welcomed |
| 10:02 | <hsivonen> | Stevef_: ok |
| 10:03 | <Stevef_> | hsivonen: my choice of words may not have been the best |
| 10:03 | <jgraham> | Stevef_: He must have done something worthwhile because a number of people seem to respect him. That doesn't change the fact that the attitudes and behaviours that he is quoted as advocatin in the article are not those that I have experienced him employing himself |
| 10:07 | <Stevef_> | jgraham: yes I understand that, which is why i mentioned the work distinction as I believe he does exhibit the qualities he is quoted as advocating in his professional accessibility work. |
| 10:13 | <hsivonen> | Stevef_: PARSER_XML_EXTERNAL ("Parser set to XML with external entities"); |
| 10:13 | <hsivonen> | doh |
| 10:13 | <hsivonen> | Stevef_: is HTML working group work nonprofessional? |
| 10:20 | <Stevef_> | hsivonen: involvement is on a voluntary basis for many of us I think not affiliated with work. is what I meant. Also in my job (professional capacity) the clients I work with are on the whole not from the standards communities, many have no idea it exists, adobe and google being the exceptions |
| 10:20 | <Stevef_> | maybe microsoft, but who knows what they know |
| 10:21 | <hsivonen> | ok |
| 10:25 | <jgraham> | (I think it seems very strange to say that one behaviour is needed to get positive action for accessibility in a "professional" context and then display quite different behaviour when trying to achieve similar things in a standards context) |
| 10:25 | <Stevef_> | hsivonen: i generally work with web app developers who build interfaces with tables and buttons using links and have little clue as to how to provide a label for a form control |
| 10:25 | <jgraham> | But what I actually wanted to ask is whether there is a good reason to fire beforescriptexecute after getting the source of the script rather than before |
| 10:26 | <jgraham> | In particular for inline scripts where beforescriptexecute changes the script text |
| 10:27 | <jgraham> | (Gecko gets thins "wrong") |
| 10:27 | <jgraham> | hsivonen: ^ |
| 10:28 | <Stevef_> | jgraham: its a 2 way street the different behaviour is often exhibited due to different responses/reactions recieved |
| 10:30 | <Stevef_> | also note that it is not binary standards/professional , its interaction with particular people or particular subgroups that makes a difference for many people |
| 10:33 | <jgraham> | Stevef_: I still don't understand why you would believe that acting in a certian way will be best at effecting change in one context and acting in a very different way will be the best way to effect the same kinds of change in a very similar context |
| 10:34 | <hsivonen> | jgraham: sicking's design. He would be a better person to answer. |
| 10:35 | <hsivonen> | jgraham: If Gecko and the specs disagree, then Hixie disagreed with Gecko. |
| 10:36 | <Stevef_> | jgraham: I don't, i am not talking about what is the best strategy for reaching one's goals I am talking about how other peoples behaviour can effects how one behaves, not in a good way |
| 10:37 | <jgraham> | hsivonen: It seems that Gecko complies with the spec in the src case |
| 10:37 | <jgraham> | Which makes sense, sort of |
| 11:20 | <Stevef_> | on another note, anyone interested in an MSAA/IA2/UIA accessibility object inspection tool for windows, developed specifically for testing web pages, can try out http://www.paciellogroup.com/blog/2012/07/latest-aviewer-alpha-2012/ feedback welcome |
| 11:35 | <smaug____> | Stevef_: make sure to file browser bugs about the issues |
| 11:36 | <Stevef_> | smaug____: yeah am in contact with various browser acc engineers on the bugs |
| 11:38 | <Stevef_> | smaug____: main issue is that chrome does not currently expose API interface to enable the tool to get at innerhtml |
| 11:38 | smaug____ | knows nothing about chrome |
| 11:39 | <smaug____> | but you mentioned few Firefox issues |
| 11:39 | <smaug____> | and would be good to have bugs filed |
| 11:39 | <Stevef_> | smaug____: i think the issues are on our/NVDAs side |
| 11:39 | <smaug____> | Stevef_: just curious, how does Opera behave ? |
| 11:39 | <smaug____> | Stevef_: ah |
| 11:39 | <odinho> | Prolly misbehaves :P |
| 11:40 | <Stevef_> | smaug____:last i checked, does not expose anything useful, unfortunately |
| 11:41 | <smaug____> | odinho was right then :) |
| 11:43 | <Stevef_> | bits of the browser chrome, none of the HTML |
| 11:51 | <odinho> | Stevef_: So, if Opera should be better, -- is there a progressive way to get there? I mean, like small feature A making it lots better, and then many more small fixes to make it progressively better. -- Or is it all requiring a big up-front investment? |
| 11:51 | <odinho> | I have no idea over Opera's accesibility, or even what tools expect to extract. |
| 11:52 | <Stevef_> | odinho: i wrote on the subject here: http://www.paciellogroup.com/blog/2012/06/open-letter-to-opera-re-accessibility-support/ |
| 11:53 | <Stevef_> | odinho: to be honest, Opera should look at implementing accessibility in its mobile browsers first (where they have marketshare) |
| 11:55 | <Stevef_> | odinho: there was an aborted attempt 5 or so years ago: http://my.opera.com/desktopteam/blog/2007/07/27/screen-reader-support |
| 11:55 | <odinho> | Stevef_: Yes, I did see that post actually. But it seems like real tasks to do stuff like that. I am doing spec stuff, tests etc, but I like doing small bug fixes on the side, so I'm always looking for really easy stuff to fix :P |
| 11:55 | <Stevef_> | adinhO; and belive there was some work on mac accessibility |
| 11:57 | <Stevef_> | odinho: right, so if you want something small scale (relaitively) that would improve access for keyboard users see discussion with hallvord: http://www.paciellogroup.com/blog/2012/07/w3c-html-and-whatwg-html-split-affect-on-html-accessibility/comment-page-1/#comment-19628 |
| 12:07 | <odinho> | Stevef_: Yeah, that one seems a bit chewable. At least after a while :-) Found the bug about it, seems like it's a very old bug (created 2001). |
| 12:07 | <odinho> | Stevef_: chaals made an extension for it as a stop-gap, https://addons.opera.com/en/extensions/details/key-title/ -- has been downloaded 905 times. |
| 12:08 | <Stevef_> | odinho: yeah I saw chaals extension, its been an issue since forever in all browsers, i have been banging on about it for at least the mid 2000's... |
| 12:09 | Stevef_ | hope to see issues fixed before retirement... |
| 12:10 | <odinho> | Stevef_: Hehe, when is that? |
| 12:10 | <Stevef_> | odinho: 20 years or so :-) |
| 12:12 | <odinho> | Stevef_: Hehe, if we haven't fixed at least the tooltip thing in that time, I will sit down and do it. |
| 12:12 | <Stevef_> | odinho: lol will hold you to that |
| 12:13 | <odinho> | ^_^ |
| 12:19 | <Stevef_> | odinho: also Opera could look at improving support for screen magnifiers on the desktop and also look at providing further features for low vision users who don't use AT, there are many of them, opera could corner the market |
| 12:50 | <sedovsek> | I wrote about CSS Flexbox Layout model, if anyone is interested > http://galjot.si/css-flexbox |
| 12:58 | <jgraham> | sedovsek: *dynamically |
| 12:59 | <sedovsek> | jgraham: Thanks. I fixed it. |
| 13:13 | <david_carlisle> | ashemedai: The comma should be in an <mo> (if it is explicit at all) or you could use mfenced and make the comma implict. All distinct character tokens in MathML are in some element or other |
| 13:13 | <jgraham> | In other news MathML is rather verbose :p |
| 13:18 | <david_carlisle> | jgraham: <word><letter>w</letter><letter>e</letter></word><space> </space><word><letter>l</letter><letter>i</letter><letter>k</letter><letter>e</letter></word><space> </space><word><letter>o</letter><letter>u</letter><letter>r</letter></word><space> </space><word><letter>t</letter><letter>a</letter><letter>g</letter><letter>s</letter></word> |
| 13:19 | <jgraham> | :) |
| 13:46 | <payman> | sedovsek: "back in in" |
| 13:46 | <sedovsek> | :P |
| 13:53 | <payman> | sedovsek: s/Another two/Other two |
| 13:55 | <sedovsek> | payman: Thanks! Fixed it. |
| 13:55 | <payman> | didn't fix the first issue though :) |
| 13:56 | <sedovsek> | Oh, yea. |
| 13:56 | <sedovsek> | Thanks again. |
| 13:56 | <payman> | np |
| 14:18 | <zewt> | matjas/annevk: definitely a bug--it doesn't matter that the character is represented as a surrogate pair; it's still one character/one codepoint |
| 14:19 | <matjas> | implementation details exposed to the user etc etc |
| 14:19 | <matjas> | either way, not really a very important issue indeed |
| 14:19 | <zewt> | and being able to backspace over half of the surrogate pair (which you can in chrome and FF) is definitely a bug--you should never be able to create a broken surrogate pair (at least not with a simple UI like that--not sure what should happen in more obscure cases, like pasting one in) |
| 14:20 | <matjas> | so who’s gonna file the bugs? /me ducks |
| 14:20 | <zewt> | the fact that non-BMP characters are so rarely used is the only reason the utf-16 fustercluck is even tolerable :) |
| 14:20 | <matjas> | haha |
| 14:21 | <matjas> | i bet no one actually uses astral symbols in passwords |
| 14:21 | <zewt> | personally I wish we'd just change JS to ucs-4, under the logic that although we'd break some sites ... it'd probably fix far more :) |
| 14:21 | <matjas> | heh |
| 14:21 | <zewt> | (unfortunately, the sites that it would break would be the few that it actually matters for, since after all they spent the time making it work) |
| 14:25 | <smus> | hey, would like to polyfill a CSS function, but it appears that there's no consistent CSS OM API so the only way this can be done is by parsing CSS via JS (yuck!). can someone point to a relevant spec? |
| 14:26 | <beverloo> | a spec for what? |
| 14:26 | <paul_irish> | (because CSSOM wont reveal anything it cant succesfully parse..) |
| 14:26 | <beverloo> | the CSS OM is specified here: http://dev.w3.org/csswg/cssom/ |
| 14:26 | <paul_irish> | well.. ideally CSSOM had a UnknownRule definition |
| 14:27 | <smus> | right. thx paul |
| 14:27 | <paul_irish> | so when it failed we could at least hack up that part with regex |
| 14:27 | <smus> | missing piece! |
| 14:27 | <paul_irish> | aside from that, the browser could expose essentially the stylesheet AST |
| 14:27 | <SimonSapin> | parsing CSS from JS? https://github.com/tabatkins/css-parser |
| 14:28 | <smus> | so if ur like background: -webkit-image("foo.webp", "foo.jpeg"); the parser just ignores that rule entirely. would be nice if it parsed as unknown |
| 14:28 | <beverloo> | the css syntax specifically defines that unknown properties/at rules need to be ignored |
| 14:28 | <paul_irish> | SimonSapin: the goal is a polyfill you'd use in production... and you can't ask folks to parse css in js clientside for real. |
| 14:29 | <paul_irish> | beverloo: sure, but you can see the problem. we can't polyfill to extend css when unknowns are discarded. |
| 14:29 | <beverloo> | the css syntax (including the rules for ignoring it) is specced here: http://www.w3.org/TR/css3-syntax/ |
| 14:29 | <beverloo> | well, you'd have to polyfill the hypothetical CSSUnknownRule too :p |
| 14:30 | <paul_irish> | hey now |
| 14:30 | <paul_irish> | i dont need to polyfill try/catch |
| 14:30 | <smus> | http://www.highdots.com/forums/javascript/retrieving-unknown-css-rules-48513.html |
| 14:30 | <smus> | specifically, http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html |
| 14:31 | <smus> | why drop unknowns? |
| 14:31 | <paul_irish> | omg. bert. |
| 14:31 | <beverloo> | it sounds like you should take this to www-style |
| 14:32 | <smus> | k, any known reason to drop unknowns? |
| 14:32 | <smus> | (so i can present a balanced case) |
| 14:33 | <paul_irish> | smus: its probably somewhere in this 2003 era archives of www style |
| 14:33 | <paul_irish> | beverloo: yeah certainly. it'd be fun to get UnknownRule back |
| 15:30 | <smus> | cool, so <img srcset> doesn't seem to work in any browser. is there an existing reference implementation? http://smus.com/m/srcset/ |
| 15:31 | <jreading> | iOS 6 mobile safari |
| 15:33 | <dglazkov> | good morning, Whatwg! |
| 15:34 | <SimonSapin> | good afternoon, dglazkov |
| 15:43 | <Wilto> | jreading: Any chance you have a link to the commit/some details handy? Curious as to whether it just covers resolution or the whole extended microsyntax. |
| 16:14 | <Velmont> | smus: ... You have an error in your syntax as well, it's with comma. |
| 16:15 | <smus> | Velmont: thx! |
| 16:30 | <jreading> | Wilto: http://trac.webkit.org/changeset/111637 |
| 16:31 | <jreading> | and a polyfill: https://github.com/SunboX/-webkit-image-set-polyfill |
| 16:31 | <jreading> | :/ |
| 16:37 | <miketaylr> | sweet README |
| 16:37 | <miketaylr> | accidentally the code |
| 16:38 | <jreading> | polyfills are the new domain squatting |
| 16:45 | <jreading> | i misspoke about srcset, it's "image-set", sorry for the confusion. *ducks* |
| 16:48 | <Hixie> | hsivonen: hey sometimes gecko and the spec disagree just because i made a mistake, or because mozilla people told me they disagree with gecko :-) |
| 18:43 | <Hixie> | hmmm |
| 18:43 | <Hixie> | i wonder how to spec the autocomplete="" field's grammar and parsing |
| 18:44 | <Hixie> | <empty> | on | off | [section] [subsection] ( generic-field | [contact-type] contact-field ) |
| 18:44 | <Hixie> | i guess to parse it i split on spaces then go backwards through the tokens |
| 18:47 | <Hixie> | and to define the conformance criteria for authors, maybe an ordered list of tokens, and i just say what each token has to be or something |
| 18:47 | <Hixie> | ok |
| 19:06 | <Wilto> | jreading: Man, that’s gonna be a tough one to polyfill. |
| 19:38 | <tantek> | Hixie, sounds horribly complicated |
| 19:39 | <Hixie> | i'm certainly open to alternatives :-) |
| 20:02 | <zewt> | okay, the chrome thing where no form of refresh will make it reload css background: url() images is pretty much horrible |
| 20:05 | <TabAtkins> | I think Inspector is gaining some Refresh options soonish, so you can do hard refreshes or even full cache flushes. |
| 20:06 | <zewt> | that's what control-f5 is supposed to do, it just appears to not propagate to css resources |
| 20:07 | <TabAtkins> | That actually sounds like a bug. File on us? |
| 20:26 | <annevk> | paul_irish: TabAtkins and I at some point came up with data-* CSS properties that would be exposed in the CSSOM |
| 20:26 | <annevk> | paul_irish: as opposed to exposing every property which would kinda ruin forward compatibility |
| 20:35 | <TabAtkins> | annevk: That's the CSS Variables spec. |
| 20:36 | <annevk> | ah yeah, it morphed into that |
| 20:36 | <TabAtkins> | Which we'll finalize for WD and soonafter LC next month at the meeting. |
| 20:36 | <TabAtkins> | But yeah, exposing every property is a non-starter. |
| 20:36 | <TabAtkins> | Like custom elements without an x- prefix or something. |
| 21:08 | <jgraham> | TimBL! |
| 22:41 | <Hixie> | TabAtkins: thanks for answering that intern's question |
| 22:41 | <Hixie> | TabAtkins: i was like "wtf are you talking about" |
| 22:44 | <TabAtkins> | Hixie: Haha, np |
| 22:44 | <TabAtkins> | I want to see the feature implemented! |
| 22:44 | <TabAtkins> | And now I have some questions to post to the list about it. |
| 22:50 | <Hixie> | i like your "just implement the spec" thing |
| 22:50 | <Hixie> | i always feel weird saying that :-) |
| 22:54 | <TabAtkins> | Why? |