| 07:03 | <ruby_on_tails> | hello |
| 07:03 | <ruby_on_tails> | I want to draw a pie using html4 canvas how do I do it ? |
| 07:04 | <espadrine> | canvas is html5 |
| 07:04 | <ruby_on_tails> | a simple circle with limited start/end angle isn't working |
| 07:04 | <ruby_on_tails> | sorry html5 was a typo |
| 07:04 | <ruby_on_tails> | or else I would ask in #html :P |
| 07:04 | <espadrine> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element |
| 07:04 | <espadrine> | This link gives the api |
| 07:05 | <ruby_on_tails> | no actually I want to get the logic of drawing a pie |
| 07:06 | <ruby_on_tails> | pie can't be drawn using an arc |
| 07:06 | <ruby_on_tails> | so what do I do ? |
| 07:07 | <espadrine> | why can't they? |
| 07:08 | <ruby_on_tails> | arc works somewhat differently it connects the start and end angles with a straight line but in a pie the line must first go to the center and then connect the other end |
| 07:09 | <Hixie> | ruby_on_tails: http://bit.ly/dyFrYu |
| 07:10 | <ruby_on_tails> | Hixie: cool, thanks |
| 07:33 | <ruby_on_tails> | Hixie: I get something like this http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Ac.fillStyle%20%3D%20c.createPattern(img3%2C%20%27repeat%27)%3B%0Ac.beginPath()%3B%0Ac.arc(500%2C%20100%2C%20100%2C%203.742133239061344%2C%206.178465552059927%2C%20true)%3B%0Ac.closePath()%3B%0Ac.fill()%3B%0Ac.restore()%3B%0A |
| 07:33 | <ruby_on_tails> | why ? |
| 07:34 | <espadrine> | You should start the path at the center using ctx.moveTo(x) |
| 07:34 | <ruby_on_tails> | oh |
| 07:34 | <ruby_on_tails> | ok, cool, thanks |
| 08:36 | <TabAtkins_> | Hixie: Check out your livedomviewer - I think you got pwned. |
| 08:36 | <TabAtkins_> | The live dom has some huge ad-based block of code attached to it. |
| 09:56 | <Philip`> | TabAtkins_: I don't see anything like that |
| 09:57 | <TabAtkins_> | Philip`: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cspan%20style%3D%22color:blue;%20%20text-decoration:%20underline;%0D%0A%22%3E01%0D%0A%3Cspan%20style%3D%22color:red;%20%20%20text-decoration:%20underline;%20%0D%0Avisibility:hidden;%22%3E11%0D%0A%3Cspan%20style%3D%22color:green;%20text-decoration:%20none;%20%0D%0Avisibility:visible;%22%3E21%0D%0A |
| 09:58 | <Philip`> | TabAtkins_: Still don't see anything unexpected |
| 09:59 | <TabAtkins_> | Huh. |
| 14:43 | <matjas> | When using XHTML5 (don’t ask), `document.compatMode` === `undefined` in WebKit. Is this a bug or am I missing something? |
| 14:48 | <matjas> | <!-- comment --><!doctype html> → does this still trigger quirks mode in HTML5? |
| 14:49 | <espadrine> | It should, I think |
| 14:50 | <Lachy> | no, it doesn't |
| 14:50 | <matjas> | It used to anyways |
| 14:50 | <hsivonen> | matjas: it has never triggered the quirks mode in HTML5 |
| 14:50 | <Lachy> | it only did in IE6, and that's been fixed since IE7 |
| 14:51 | <matjas> | hsivonen: Yeah, but it used to before (right?), that’s what I meant |
| 14:51 | <hsivonen> | matjas: only in IE |
| 14:51 | <hsivonen> | (IIRC) |
| 14:52 | <matjas> | So is <!-- comment --><!doctype html> still a problem in IE6, or is that only the case for other DOCTYPEs? |
| 15:10 | <hsivonen> | matjas: <!-- comment --><!doctype html> is quirks in IE6 |
| 15:10 | <hsivonen> | (yes, I actually tested) |
| 15:11 | <Workshiva> | He uses IE6, burn him! |
| 15:11 | <matjas> | hsivonen: Thanks. Out of curiosity, how did you test it? Is there a bulletproof way to detect quirks/standards mode? |
| 15:11 | <Workshiva> | document.compatMode? |
| 15:11 | <matjas> | alert(document.compatMode === 'CSS1Compat' ? 'Standards mode' : 'Quirks mode'); |
| 15:12 | <matjas> | Like that? |
| 15:12 | <matjas> | I’m asking because… [15:49:02] <matjas> When using XHTML5 (don’t ask), `document.compatMode` === `undefined` in WebKit. Is this a bug or am I missing something? |
| 15:12 | <hsivonen> | matjas: http://hsivonen.iki.fi/doctype/test-quirks.php?doctype=%3C!--+comment+--%3E%3C!DOCTYPE+html%3E |
| 15:12 | <Workshiva> | There is no quirks mode in XHTML5 |
| 15:13 | <hsivonen> | I looked at the rendering of the boxes under "Mac IE 5, Windows IE 6&7 and Opera 7 & 8 Test (Not applicable to Opera 9!)" |
| 15:13 | <matjas> | Workshiva: Looks like in WebKit, there’s no document.compatMode either |
| 15:13 | <Ms2ger> | matjas, bug in WebKit |
| 15:13 | <matjas> | Thanks hsivonen |
| 15:13 | <matjas> | Thanks Ms2ger, I’ll file it then |
| 15:14 | <Ms2ger> | Thanks |
| 15:25 | <matjas> | Ms2ger and others who might be interested — here’s the bug ticket: https://bugs.webkit.org/show_bug.cgi?id=44422 |
| 15:28 | <tantek> | What are the chances that scoped style sheets will get dropped from HTML5? |
| 15:28 | <tantek> | Does anyone implement them at all? (not AFAIK) |
| 15:30 | <hsivonen> | tantek: my understanding is that they are in the spec in the hope that two UAs implement them. if not, the Process requires taking the feature out in a later transition stage. |
| 15:30 | <hsivonen> | (I'm not aware of any implementations) |
| 15:30 | <tantek> | that's an unusually optimistic approach towards a new feature, given how many totally new features are rejected |
| 15:30 | <tantek> | ok |
| 15:31 | <hsivonen> | tantek: <style scoped> has been in the spec for quite some time, so it predates many current spec editing patterns |
| 15:31 | <tantek> | ah ok - early new idea - gotcha |
| 15:31 | <tantek> | thanks for the background |
| 15:56 | <jgraham> | Oooh hsivonen is back |
| 15:57 | <jgraham> | hsivonen: I hope you had a nice vacation :) |
| 15:58 | <hsivonen> | jgraham: I did. thanks |
| 16:00 | <hsivonen> | It's good to go off the grid into the wilderness where phones don't work sometimes |
| 16:00 | <hsivonen> | the downside is that Google Maps doesn't work, either, there |
| 16:00 | <hsivonen> | not that batteries would last anyway |
| 19:54 | <Hixie> | TabAtkins: i think you got pwned by your ISP, i don't see it |
| 19:54 | <Hixie> | tantek: <style scoped> was one of those things i added on the principle that so many people want it that it's a no brainer that it'd get implemented. ;-) |
| 19:55 | <tantek> | Hixie, makes complete sense. :) |
| 19:56 | <Ms2ger> | Hixie, please leave your sense of logic at the door |
| 19:57 | <Hixie> | Ms2ger: yeah, as demonstrated by the complete lack of implementations, shows what i know ;-) |
| 19:57 | <Hixie> | ping="" was the added for similar reasons -- it seemed like such an obvious user win |
| 19:57 | <Hixie> | and then somehow it became the evilest feature in the spec |
| 19:57 | <Hixie> | so... |
| 19:58 | <Ms2ger> | Are you suggesting you thought that people would consider the pros and cons of a feature before judging it? |
| 20:01 | <Hixie> | more that the pros and cons were so obvious there was no need to worry about people not considering them |
| 20:02 | <Ms2ger> | I might be a little more cynical than you were, then :) |
| 20:02 | <AryehGregor> | If ping="" were actually used by authors, implementers would immediately be under pressure from users to disable it. The situation where ping="" works and is used is a Pareto improvement over the situation where it doesn't exist, but the latter is a Nash equilibrium and the former is not. |
| 20:02 | <AryehGregor> | There have been similar cases where the feature has actually worked, though. |
| 20:02 | <AryehGregor> | Like autocomplete=false. |
| 20:03 | <AryehGregor> | But users are more sympathetic to "banks don't want to get hacked" than "Google wants to track you more efficiently", I guess. |
| 20:05 | <Rik`> | ping is a cool idea to give more control but authors wouldn't use it that much since it can easily be bypassed |
| 20:05 | <AryehGregor> | Kind of like if you asked them to use an <advertisement> tag for all ads. There are some semantics that authors explicitly do not want to be machine-readable. |
| 20:06 | <AryehGregor> | Or even more extreme, if you asked them to put alt text on their captchas. :) |
| 20:06 | <othermaciej> | autocomplete=false works due to banks being willing to lock out browsers, not due to user sympathy |
| 20:07 | <AryehGregor> | Is that how it arose? Did banks just only allow browsers that respected it, in the early days? |
| 20:07 | <AryehGregor> | That explains the situation neatly. |
| 20:07 | <othermaciej> | I don't know if it arose that way, but I know at least some banks are now willing to lock out browsers that do not respect it |
| 20:08 | <AryehGregor> | So there's your equilibrium. |
| 20:10 | <Hixie> | Ms2ger: it was many years ago, i've grown more cynical since :-) |
| 20:11 | <Ms2ger> | Hixie, hard not to, I guess |
| 20:12 | <Hixie> | AryehGregor: in a sane world, there'd be no point pressuring people to disable ping="", since that would just make sites not use it, and would thus lose all the benefits |
| 20:13 | <AryehGregor> | Hixie, only if browsers can coordinate sufficiently. If each implementer is deciding independently, then they gain (at least temporarily) from disabling it if all other browsers have it enabled, because that way they temporarily protect privacy better. |
| 20:13 | <AryehGregor> | Of course, in the medium term they gain nothing, but they don't lose anything either relative to the other browsers. |
| 20:13 | <Hixie> | i'm talking about users losing out |
| 20:15 | <Rik`> | it's obvious that ping will be less reliable than the situation right now |
| 20:15 | <AryehGregor> | You're looking at different possible worlds and identifying the one that's better, without sufficient regard to the fact that you need decision-makers to have the correct incentives to play along. Implementer incentives don't exist for ping="", for any particular implementer. |
| 20:15 | <Rik`> | it takes 5 minutes to write an extension to disable ping |
| 20:15 | <AryehGregor> | Implementing it can only strictly increase the amount of tracking done on your users. |
| 20:16 | <Rik`> | AryehGregor: increase ? |
| 20:16 | <AryehGregor> | Yes. |
| 20:16 | <AryehGregor> | As long as at least one site uses ping. |
| 20:16 | <AryehGregor> | Rik`, there are plenty of extensions to disable redirect URLs of various types. They'll certainly handle the big players like Google reliably already. |
| 20:16 | <AryehGregor> | But yes, it would be easier to disable ping. |
| 20:16 | <Rik`> | how can you disable redirect urls ? |
| 20:17 | <AryehGregor> | Have the extension detect and rewrite them. |
| 20:17 | <AryehGregor> | Maybe using a fixed set of patterns for popular sites, maybe using heuristics. |
| 20:17 | <Hixie> | ping="" has benefits for the sites too |
| 20:17 | <Hixie> | one of the main benefits is that it reduces latency compared to the redirect method |
| 20:18 | <AryehGregor> | It has benefits for sites and users. It has only drawbacks for implementers. |
| 20:18 | <AryehGregor> | At least if you consider them one at a time. |
| 20:18 | <AryehGregor> | Not a Nash equilibrium. The incentives all lean toward defecting. |
| 20:19 | <Rik`> | Hixie: that's why it's a good idea, but does it make sense to have less reliable data with only that benefit ? |
| 20:19 | <AryehGregor> | Unlike with most features, where they pressure you to conform so that your page renders the same (unless you have a large market share and want to mess up anyone else). |
| 20:19 | <Rik`> | AryehGregor: I don't see how it has drawbacks for implementers |
| 20:19 | <Rik`> | AryehGregor: a site willing to use ping would have to detect @ping support to provide a fallback for non supporting browsers |
| 20:20 | <AryehGregor> | Rik`, because users don't like being tracked. A browser that implements it can only possibly cause more tracking of its users. Thus the incentive is for browsers to not implement it (*especially* if it's widely used) so that they can tell their users that they're tracked less. |
| 20:20 | <Hixie> | Rik`: on the long run, once everyone supports ping="", yes |
| 20:20 | <Hixie> | Rik`: because the data you'd miss out on is the data from people who would have opted out of whatever server-side solution you had |
| 20:20 | <AryehGregor> | This holds as long as at least one site does ping="" without fallback. |
| 20:21 | <AryehGregor> | You have to look at the incentives for the individual actors, not the relative merits of particular situations. |
| 20:21 | <Rik`> | AryehGregor: why would a website implement ping without fallback? |
| 20:21 | <AryehGregor> | Because it's easy. |
| 20:21 | <AryehGregor> | Also, browsers could just lie. |
| 20:22 | <AryehGregor> | They already lie about tons of things (just look at the UA string). |
| 20:22 | <Rik`> | the next day the metrics team would tell them that they have far less data |
| 20:22 | <AryehGregor> | Sure, maybe. |
| 20:22 | <AryehGregor> | It would be temporary, as I said. |
| 20:23 | <Rik`> | you're also assuming that the marketing would think implementing ping is bad for privacy |
| 20:23 | <Rik`> | whereas it's the contrary, it gives the user even more control |
| 20:23 | <AryehGregor> | Suppose everyone implemented ping. |
| 20:24 | <Hixie> | on a more concrete note, any csswg people around? |
| 20:24 | <AryehGregor> | Then suppose I go to Firefox (or whatever) and complain: "Hey! You're sending data to Company X about my browsing habits. You could disable this with a few lines of code, in which case all sites using ping without fallback will stop collecting data on Firefox users (at least temporarily). If you care about user privacy, you should disable ping." |
| 20:25 | <AryehGregor> | Then either they do, or someone else does . . . then that browser will temporarily be more private, so some users will move to it, Slashdot will have a story about how it protects your privacy better . . . then the feature is useless since it's completely unreliable, so everyone stops using it, so all the browsers stop implementing it. |
| 20:26 | <Workshiva> | Sort of like how ads are useless because everyone has ad blockers? |
| 20:26 | <AryehGregor> | Yes, if all ads were in an <advertisement> tag and browsers could easily just ignore them. |
| 20:26 | <AryehGregor> | (without false positives or much work) |
| 20:26 | <Workshiva> | Browsers could also easily ship with ad filters |
| 20:26 | <AryehGregor> | They do. |
| 20:27 | <Workshiva> | No, they don't |
| 20:27 | <AryehGregor> | (for pop-up ads, at least) |
| 20:27 | <AryehGregor> | Not for all types of ads. |
| 20:27 | <Rik`> | they already ship with malware filters |
| 20:27 | <AryehGregor> | They could be more aggressive about ad filtering, it's true. I've wondered before why no one is willing to take that step. |
| 20:27 | <AryehGregor> | It's a competitive market, after all. |
| 20:28 | <Rik`> | AryehGregor: because they all take money from Google ? |
| 20:28 | <AryehGregor> | Microsoft, Apple, and Opera take money from Google? |
| 20:28 | <Rik`> | yes |
| 20:28 | <AryehGregor> | . . . what money? |
| 20:29 | <Rik`> | being the default search engine |
| 20:29 | <AryehGregor> | Google isn't the default search engine in IE, I'm awfully sure of that. |
| 20:29 | <Workshiva> | Maybe not Microsoft, but they have enough business interests otherwise |
| 20:29 | <Rik`> | and a percentage of ads clicked on the search results |
| 20:29 | <AryehGregor> | I also thought Yahoo! was the default search engine in Opera, but it seems that's changed, or maybe was never true. |
| 20:29 | <Workshiva> | Yahoo is the default (or was) on the speed dial only |
| 20:30 | <Rik`> | yeah, not Microsoft, but they take money from Bing :) |
| 20:30 | <AryehGregor> | I doubt Apple receives enough money from Google to be of consequence to their business, compared to their strategic interest in weakening Google. |
| 20:30 | <Rik`> | I said Google but you can replace it with "search engines" |
| 20:30 | <AryehGregor> | But Microsoft doesn't make its money from advertising. |
| 20:30 | <AryehGregor> | It makes it from software sales. |
| 20:30 | <Rik`> | mostly |
| 20:30 | <AryehGregor> | It probably only runs an ad network at all to try leeching business from Google. |
| 20:30 | <AryehGregor> | Overwhelmingly, not mostly. |
| 20:30 | <Workshiva> | That just makes it worse |
| 20:31 | <AryehGregor> | If all web advertising collapsed tomorrow, it would destroy Google while leaving Apple and Microsoft almost unscathed (at least directly). |
| 20:31 | <AryehGregor> | Maybe Microsoft would be afraid of antitrust suits if it blocked Google ads. |
| 20:31 | <Rik`> | but they know Windows and Office won't be there forever |
| 20:31 | <AryehGregor> | They'll be there for the next five years, and no one plans ahead further than that. |
| 20:31 | <Rik`> | and Apple can't "kill" Google, they have business deals (think Google Maps on iOs) |
| 20:31 | <AryehGregor> | Plus, MS has tens of billions of dollars in cash. |
| 20:32 | <Rik`> | if MS kills ads, it also kills a lot of websites relying on Google ads |
| 20:33 | <AryehGregor> | The point is, MS and Apple are not going to be harmed much overall by making ads less profitable, but one of their biggest competitors will be harmed a lot, so they surely have an interest in hurting ad profitability. |
| 20:33 | <AryehGregor> | Plus they have a large immediate interest in encouraging users to use their browser because it blocks ads by default. |
| 20:33 | <AryehGregor> | So I'm really wondering why no one's tried it. |
| 20:34 | <Rik`> | it's an ecosystem |
| 20:35 | <AryehGregor> | Sure, but as competition increases, the actors are forced to start looking more to their short-term interest or become irrelevant. |
| 20:35 | <Workshiva> | What about the fact that microsoft runs a lot of ads themselves? |
| 20:35 | <Rik`> | if a browser adds a default filtering, websites will block access |
| 20:36 | <AryehGregor> | That's a point. |
| 20:36 | <Rik`> | why wasting bandwith if you're not paid ? |
| 20:36 | <AryehGregor> | Which brings us back to the observation about why browsers have to support autocomplete=false. |
| 20:37 | <Rik`> | AryehGregor: btw, have you found mobile wikipedia source code ? |
| 20:37 | <AryehGregor> | On the other hand, no one much blocked browsers that implemented popup blockers, right? Browsers could still block progressively more of the annoying ads while still leaving ways to advertise. |
| 20:37 | <AryehGregor> | Rik`, dunno, but Googling "mobile wikipedia git" gives http://github.com/hcatlin/wikimedia-mobile/ as the first result. |
| 20:39 | <Rik`> | oh great |
| 20:49 | MikeSmith | catches up with some other list mail and notices that Webkit project will finally be renaming their LayoutTests stuff |
| 20:51 | MikeSmith | now gets to thread about dumpAsMarkup |
| 22:17 | <webben> | AryehGregor: I think you may be underestimating the impact of MS's own ad business: http://online.wsj.com/article/SB10001424052748703467304575383530439838568.html |
| 22:17 | <AryehGregor> | Am I the only one who has never heard a TV ad that plays back louder than the content? |
| 22:18 | <Ms2ger> | Me not either, but I don't watch TV |
| 22:19 | <AryehGregor> | webben, maybe. I think sites blocking the browser is a more plausible reason for why they don't get too aggressive, though. |
| 22:19 | <AryehGregor> | Plus the trickiness of getting the heuristics right, without resorting to domain-based blacklists (which AdBlock can get away with, major browsers maybe not). |
| 22:20 | <MikeSmith> | Peter`: http://peter.sh/2010/08/last-week-in-webkit-and-chromium/ is great |
| 22:22 | <MikeSmith> | I was going to say I wonder if dumpAsMarkup might have deserved a mention |
| 22:22 | <MikeSmith> | but I guess that change went in a long while back |
| 22:22 | <MikeSmith> | I had just not caught up on webkit-dev mail until today |
| 22:22 | <Peter-> | it isn't in last week's changelogs |
| 22:22 | <MikeSmith> | yeah |
| 22:24 | <Peter-> | http://peter.sh/data/last-week/chromium/report-week-33.html btw :p |
| 22:25 | <Peter-> | and thank you |
| 22:26 | <Rik`> | I should have coded something like this when I was doing those weekly summaries |
| 22:26 | <Peter-> | there's http://peter.sh/data/last-week/webkit/report-week-33.html for webkit |
| 22:27 | <Peter-> | I'm going to create such a page for Mozilla as well, through I haven't compiled Mercurial support in yet |
| 22:30 | <MikeSmith> | hmm, 396 Webkit commits during the week, 717 Chromium commits |
| 22:30 | <Rik`> | MikeSmith: chromium is a browser |
| 22:30 | <MikeSmith> | true |
| 22:30 | <Rik`> | Peter-: Mozilla commits are harder to understand, commit messages are one liners |
| 22:31 | <Peter-> | I can perfectly read code, so I'm not expecting any huge problems with that |
| 22:31 | <Peter-> | though I agree it's more inconvenient |
| 22:32 | <Rik`> | yeah harder to get a sense of what's going on quickly |
| 22:34 | <MikeSmith> | I'm noticing that abarth and Eric's Treebuilder failure triage page is now down to just 19 items |
| 22:34 | <MikeSmith> | oh |
| 22:34 | <MikeSmith> | or maybe not |
| 22:34 | <abarth> | MikeSmith: yeah, the grey ones are not bugs |
| 22:34 | <abarth> | the tree builder is turned on |
| 22:34 | <MikeSmith> | ok |
| 22:34 | <abarth> | we're working on fragment parsing |
| 22:34 | <MikeSmith> | yeah, I saw that |
| 22:34 | <abarth> | we have three test failures left |
| 22:35 | <MikeSmith> | beautiful |
| 22:35 | <MikeSmith> | what about entities? |
| 22:38 | <abarth> | entities are done |
| 23:30 | <karlcow> | http://www.iamcal.com/png-store/ |
| 23:33 | <KaOSoFt> | karlcow- :o |
| 23:36 | <AryehGregor> | Summary: for text, gzip works better than trying to encode as a PNG. |
| 23:36 | <AryehGregor> | I can't say I'm completely surprised. |
| 23:42 | <Dashiva> | Not much of a difference |
| 23:42 | <Dashiva> | Less than 1% it looks like? |
| 23:43 | <Dashiva> | Not bad for compression that's server-independent |
| 23:43 | <Rik`> | gzip is server independent |
| 23:45 | <Dashiva> | Are you saying browsers would sniff out that a script src was actually a .js.gz? |
| 23:47 | <Rik`> | with the right headers I can serve a gzipped JS, yes |
| 23:47 | <Rik`> | content negociation is only there to check browser support |
| 23:47 | <Dashiva> | Sure, but then it isn't server-independent anymore |
| 23:47 | <Rik`> | on your desktop, it will work too |
| 23:48 | <Dashiva> | Oh, I think we have a misunderstanding |
| 23:48 | <Dashiva> | I don't mean that it would work without a server. I mean it would work without requiring server support. |
| 23:49 | <Rik`> | no it won't |
| 23:49 | <Rik`> | you need to tell your server to serve your images with the right content-type |
| 23:49 | <Dashiva> | Why? Browsers sniff images |
| 23:49 | <Rik`> | I don't think Firefox does |
| 23:50 | <Rik`> | or is it Safari ? |
| 23:51 | <Rik`> | anyway, I'm pretty sure one browser does not do sniffing |
| 23:52 | <Dashiva> | I'm sure abarth can tell us when he returns :) |
| 23:53 | <abarth> | hi |
| 23:53 | <abarth> | all browsers sniff images |
| 23:54 | <Rik`> | I'm pretty sure I've seen a bunch of strange characters when viewing some images sent as text/plain |
| 23:54 | <abarth> | to be more precise |
| 23:55 | <abarth> | the <img> element ignore the content-type header |
| 23:55 | <abarth> | what happens when you load an image in a frame is more complex |
| 23:56 | <Rik`> | is it the same for CSS backgrounds ? |
| 23:58 | <abarth> | not sure |
| 23:58 | <abarth> | probably |
| 23:59 | <Rik`> | anyway, the PNG technique is quite useless |