| 00:04 | <tantek_> | Hixie - this kind of problem has made me consider using CSS for such things, such that the user could always override such dumb behavior with their user style sheet. |
| 00:05 | <tantek_> | (zewt's autocomplete=off frustrations) |
| 00:12 | <astro73> | Sorry for being OT, is there a channel for WebSockets? |
| 00:13 | <Hixie> | astro73: this is on-topic if you don't mind people being snarky about it at the same time :-) |
| 00:13 | <Hixie> | astro73: #html5 might be better if you have authoring help (as opposed to wanting to discuss the spec itself, where this channel is very much the right one) |
| 00:14 | <astro73> | I'm actually looking for software supporting it |
| 00:14 | <Hixie> | client or server? |
| 00:15 | <astro73> | a reverse proxy capable of: SSL unwrapping, dispatch by URL, and can handle WebSockets |
| 00:15 | <Hixie> | ah, dunno then |
| 00:19 | <astro73> | I know that nginx and haproxy can't do dispatch and websocket at the same time. mod_proxy and apsis's pound can't handle ws (although there was an article once that said pound could) |
| 00:25 | <astro73> | but https://github.com/nodejitsu/node-http-proxy looks promising |
| 00:25 | <crankharder> | in indexedDB, everything is even driven, so, var request = window.indxedDB.open('foo') ; request.onsuccess = function(){alert('do stuff')}. One thing I've never understood is what the timing is like of calling open(), which just returns a 'request' and then setting the onsuccess handler afterwards. at no point do I see where the opening of the DB is triggered. i think i'm missing something fundamental about how indxedDB events are |
| 00:25 | <crankharder> | example: https://developer.mozilla.org/en/IndexedDB/IDBFactory#Example |
| 00:28 | <TabAtkins> | Events can't fire while your code is running - they need to wait for you to yield back to the event loop. So, as long as you don't put the "request.onsuccess = ..." line in a setTimeout or something, you'll be fine. |
| 00:28 | <TabAtkins> | The listeners will be wired up before any events fire, and the events will go off automatically sometime after you yield to the event loop. |
| 00:29 | <crankharder> | so the event wont fire till after i set onsuccess then? |
| 00:29 | <TabAtkins> | Yes. |
| 00:29 | <TabAtkins> | It won't fire until your currently-executing function is completely done, actually. |
| 00:30 | <crankharder> | ok that makes sense |
| 04:37 | <llrcombs> | http://arstechnica.com/microsoft/news/2012/02/no-third-party-code-on-the-windows-on-arm-desktop-means-no-plugins-for-internet-explorer.ars <-- No Flash on Windows on ARM, period. YES! |
| 09:46 | <jgraham> | So, at risk of causing alarm and confusion, I made a html5lib release |
| 09:46 | <jgraham> | I even fixed a bug! |
| 09:46 | <jgraham> | There are a couple of remaining issues in the tests though, so I didn't call it 1.0 |
| 09:48 | <jgraham> | I am quite tempted to swicth the repo to git so that the whole thing can be mirrored on github since people seem to assume that anything that's not on github doesn't exist these days |
| 09:50 | <jgraham> | (Google code still has better tools e.g. side-by-side diff views, which might be important if we ever used them) |
| 10:41 | <Philip`> | (It's odd that a decentralised VCS has by far the most centralised community of any VCS) |
| 10:51 | <jgraham> | (I'm not sure it's really the VCSs that have a community though) |
| 11:22 | <Taggnostr> | if we have </li</ul>, we start from http://www.w3.org/TR/html5/tokenization.html#end-tag-open-state , 'l' is a latin small letter, so we move on to "tag name state", we follow that and consume the i and the < as part of the tag name, but then there's a /, and that apparently means "Switch to the self-closing start tag state." |
| 11:23 | <Taggnostr> | isn't this wrong considering that </li is already an end tag? |
| 11:27 | <Philip`> | I think it's just the state name that's misleading |
| 11:28 | <Philip`> | (Maybe "self-closing tag state" would be clearer) |
| 11:29 | <Taggnostr> | so in this case if I go to the "self-closing start tag state" I see 3 options, if there's a > I will emit what I got so far (as an end tag), if not I keep moving on |
| 11:30 | <Taggnostr> | so in this case I should go back and keep consuming till ul, and then emit 'li</ul', right? |
| 11:30 | <Taggnostr> | "self-closing tag state" is a bit better but afaiu there's nothing self-closing here |
| 11:31 | <Philip`> | "self-closing start tag or bogus end tag that looks quite like a self-closing start tag state" |
| 11:31 | <Taggnostr> | where "here" would be e.g. </li/> or </li</>ul> |
| 11:32 | <Philip`> | From self-closing start tag state, it says to reconsume the "/" in before attribute name state |
| 11:32 | <Taggnostr> | if it's not followed by > |
| 11:33 | <Philip`> | Oops, not "/" |
| 11:33 | <Philip`> | In self-closing start tag state it will see the "u" next, and reconsume that in before attribute name state |
| 11:34 | <Philip`> | which will make it create an attribute named "ul" |
| 11:35 | <Taggnostr> | so with </li</ul> I should emit a closing 'li</' and discard an 'ul' attribute, right? |
| 11:35 | <Philip`> | The tag name will be "li<", because the tag name state does not append the "/" to the tag name |
| 11:36 | <Taggnostr> | indeed |
| 11:37 | <Philip`> | ("l" appends, "i" appends, "<" appends, "/" causes switch to self-closing state, "u" gets reconsumed in before attribute name state, "u" starts attribute name, "l" appends, ">" ends tag, I think) |
| 11:38 | <Taggnostr> | makes sense |
| 11:38 | <Philip`> | Really? Something must be wrong |
| 11:38 | <Philip`> | HTML should never make sense :-p |
| 11:38 | <Taggnostr> | s/makes sense/sounds like a correct interpretation of the standard/ |
| 11:39 | <Philip`> | Matches the output of http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0D%0A%3Cli%3C%2Ful%3E too |
| 11:39 | <Taggnostr> | what's "LIU00003C" ? |
| 11:40 | <Taggnostr> | U00003C == <? |
| 11:40 | <Philip`> | Yes |
| 11:40 | <Taggnostr> | why that weird notation? |
| 11:40 | <Philip`> | document.createElement("li<") is not allowed |
| 11:41 | <Philip`> | (and that DOM viewer uses createElement) |
| 11:41 | <Taggnostr> | why not LI\x3C or LI\u003c? |
| 11:41 | <Philip`> | You probably can't have "\" either |
| 11:41 | <Taggnostr> | does createElement even recognize U00003C as <? |
| 11:42 | <Taggnostr> | actually "LI\x3C" should be exactly the same as "LI<" |
| 11:43 | <Philip`> | No, it's just a relatively unambiguous way to represent the name without making createElement throw exceptions |
| 11:43 | <Philip`> | (Also it matches http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#coercing-an-html-dom-into-an-infoset ) |
| 11:45 | <Taggnostr> | it's the first time I see this notation |
| 11:47 | <Philip`> | I don't know if anyone in the world other than hsivonen uses that notation |
| 12:13 | <krijn> | Five years, wow |
| 12:14 | <krijn> | People, I might have to stop the IRC logging thingy |
| 12:14 | <smaug____> | no no |
| 12:15 | <krijn> | We're moving away from this office, and I don't know if I can hook up my silly server somewhere else |
| 12:15 | <smaug____> | I'll buy you a beer if you keep logging IRC. |
| 12:15 | <krijn> | Beer won't pay the rent here, unfortunately :) |
| 12:16 | <Philip`> | How about buying a server? :-) |
| 12:16 | <smaug____> | are you sure? Just make the landlord to drink it (and perhaps few other beers) |
| 12:16 | <krijn> | I'll probably move my domain to a static place, so the urls will just keep on working |
| 12:16 | <smaug____> | krijn: what is the schedule for the move? |
| 12:17 | <krijn> | Somewhere between April and July |
| 12:17 | <smaug____> | would be great to get replacement for your logging before that |
| 12:17 | <smaug____> | ok |
| 12:17 | <smaug____> | hmm, perhaps Mozilla could do the logging |
| 12:17 | <krijn> | Perhaps we can transfer the internet account as well, then it's not a problem and I'll just hook it up in the new place |
| 12:18 | <krijn> | But at least that will take some days off :) |
| 12:19 | <krijn> | </dramaqueen> |
| 12:22 | <Philip`> | krijn: If you're unable to keep running it on your server, would it be feasible to move the data and code to someone else's server? |
| 12:22 | <krijn> | Of course |
| 12:23 | <krijn> | I'll do that anyway |
| 12:23 | <krijn> | So the data won't be lost |
| 12:23 | <krijn> | But the logging itself, don't know |
| 12:27 | <krijn> | (Can't run IRC software on my normal server, that's why I'm running kh.nl on my home machine) |
| 12:30 | <svl> | How flexible is the display software? Can it easily be changed to parse logs in a slightly different format? Cause then you could run an existing irc bot, and use its logs as input |
| 12:31 | <krijn> | It only requires some naming conventions now |
| 12:32 | <krijn> | A log file for each channel for each day, only requiring line endings in the file itself |
| 12:34 | <svl> | Sounds like that should be a workable solution, then. Or is the limitation to running IRC software on your normal server not technical, but rather that your hosting provider doesn't allow it? |
| 12:35 | <krijn> | Both, I think, plus my brain doesn't get how that would work |
| 12:35 | <krijn> | This Windows + mIRC configuration, I get how that works :) |
| 12:42 | <krijn> | Anyways, I'll make sure the URLs will just keep on working. Worst case scenario is I won't flood the interwebs with new ones starting somewhere between April and July. |
| 12:44 | <Philip`> | You say "flood the interwebs", I say "bless the world with our pearls of wisdom" |
| 12:45 | <krijn> | About 300MB of it, yeah |
| 12:46 | <Philip`> | We offer very many pearls |
| 12:46 | <krijn> | :) |
| 13:03 | <kennyluck> | We need to the logger…. |
| 13:47 | <annevk> | hmm yeah we should sort something out |
| 13:48 | <annevk> | maybe the W3C can help out, I heard shepazu was looking into better loggging |
| 13:51 | <Taggnostr> | Philip`, in case you want to take a look, this is the result: http://bugs.python.org/review/13993/patch/4169/14344?context=10&column_width=80 |
| 13:52 | <Taggnostr> | I didn't implement the full attribute parsing for the closing tag |
| 14:12 | <Philip`> | Taggnostr: How does <img src="URL><//img></html</html> produce a comment "/img" (if I'm reading the test correctly)? The src attribute value ought to continue until EOF |
| 14:18 | <Philip`> | Taggnostr: You should never get \r in the element name, because http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#preprocessing-the-input-stream converts any CR or CRLF into LF before the tokeniser sees it |
| 14:18 | <Philip`> | (which is why the tokeniser algorithm doesn't bother saying to treat CR like any other whitespace character) |
| 14:20 | <Philip`> | If you don't do that input stream preprocessing, and don't handle \r in an intentionally spec-violating way, then you won't be tokenising input like "</li\r\n>" in a sensible way |
| 14:23 | <Taggnostr> | Philip`, indeed |
| 14:25 | <Taggnostr> | and I don't know about the first question (yet) |
| 14:25 | <kennyluck> | python…. why doesn't Python just switch to html5lib ? |
| 14:25 | <Taggnostr> | for the reasons I said yesterday |
| 14:25 | <Taggnostr> | it might actually happen at some point in the future |
| 14:26 | kennyluck | is reading logs. So apparently the log is very useful. |
| 14:28 | Philip` | wonders whether general Python people agree that they should be parsing HTML compatibly with the HTML5 parsing algorithm, and the question is just how to best implement that (e.g. adopting html5lib vs evolving HTMLParser), or whether the concept of HTML5 isn't accepted yet |
| 14:30 | <annevk> | html5lib is presumably too slow? |
| 14:30 | <Taggnostr> | we don't have any "html expert" except me and a couple of other devs that more or less care about html5, but moving toward HTML5 is fine |
| 14:31 | <Taggnostr> | and right now it's "easier" to fix the existing parser rather than adding a new one |
| 14:31 | <Taggnostr> | even if we add html5lib, that will happen for 3.3/3.4, and what I'm fixing also goes to 2.7/3.2 |
| 14:32 | <annevk> | yay for you then :) |
| 14:33 | <kennyluck> | I'll go for porting html5lib to C if we really want to make it fast. |
| 14:33 | <gsnedders> | annevk: html5lib isn't that much slower than HTMLParser, IIRC |
| 14:34 | <gsnedders> | And html5lib needs a fair bit of work to get it fully working under Py3. |
| 14:34 | <Taggnostr> | I was thinking about writing a lightweight version of html5lib without error reporting, but that's just a thought, I haven't checked if html5lib is really slower and if removing the error reporting will make it faster |
| 14:35 | <annevk> | kk |
| 14:37 | <kennyluck> | That makes sense. I don't think general users of this library care about error reporting. They just want a data mining tool compatible with the browsers. |
| 14:37 | <Philip`> | If I remember correctly, what made it slow was scanning through every character in the string (either in a loop or with regexps) |
| 14:37 | <Taggnostr> | the idea is to use an approach similar to HTMLParser, so having a regex that matches everything that is valid, rather than going through several states and different functions every time |
| 14:37 | <Philip`> | which is unavoidable when you're parsing a string |
| 14:37 | <Philip`> | All the actual token generation and error detection and tree construction etc was a minor part of the total cost |
| 14:38 | <Taggnostr> | but what seems problematic to me is all the functions calls involved with the state changes |
| 14:38 | <Taggnostr> | (I might be completely wrong though) |
| 14:42 | <Taggnostr> | Philip`, I fixed the \r now, thanks for spotting it! |
| 14:44 | <Philip`> | I think the actual number of states has little effect on performance, so the best way to test performance is probably by using a trivial subset of the syntax (I just did characters and tag names (no attributes, no error handling, etc) when experimenting ages ago) and then measure what's the fastest way of generating tokens |
| 14:44 | <Philip`> | and then all the real states can be added on afterwards in the same style |
| 14:44 | <Taggnostr> | Philip`, usually function calls are expensive, and for something as simple as <foo attr="value"> there are like a dozen of states |
| 14:45 | <Taggnostr> | so a dozen function calls, and a single regex should be much faster than that |
| 14:46 | <Taggnostr> | unless you keep all in a huge loop with a switch inside |
| 14:46 | <Taggnostr> | s/all/everything/ |
| 14:48 | <gsnedders> | Taggnostr: Nowadays there's no real bottleneck in html5lib under CPython, AFAIK |
| 14:51 | <Taggnostr> | ok, I haven't really looked at the performances |
| 14:52 | <Taggnostr> | gsnedders, what is missing to html5lib in order to work under py3? |
| 14:52 | <Philip`> | I think the main thing that's been missing is a reason to care about Python 3 |
| 14:53 | <Taggnostr> | but does it need to be ported? is it ported already but not up to date? or the port is more or less working but still incomplete? |
| 14:53 | <Philip`> | (or to care enough to sort out the byte/character-related issues that 2to3 can't handle, or something like that) |
| 14:54 | <Taggnostr> | on py3 html.parser only works with unicode |
| 14:54 | <Philip`> | If I remember correctly (which I probably don't), it was ported partly with 2to3 and partly by hand, several years ago, and probably never worked properly, and then was not maintained |
| 14:55 | <Taggnostr> | 2to3 usually don't touch bytes/string because on py2 they were used for both |
| 14:55 | <Taggnostr> | it might be an interesting gsoc project |
| 14:56 | <Philip`> | I imagine it's important to have a strategy for maintaining both branches in parallel, else one of them will quickly fall behind again |
| 14:56 | <Taggnostr> | how active is html5lib? |
| 14:57 | <Philip`> | http://code.google.com/p/html5lib/updates/list says not very |
| 14:57 | <Taggnostr> | I guess that if I get involved in this I will end up maintaining the py3 port |
| 14:58 | <Philip`> | I suppose it's easy for spec-related changes, since they will add tests and it's easy to verify that both versions pass all the tests |
| 14:58 | <gsnedders> | Taggnostr: 2to3 creates something that fails more TCs than under Python2. |
| 14:58 | <Taggnostr> | if it also gets included in the stdlib things will be a bit different, because the version included in the stdlib will become the main one, and possibly things will be backported to an external py2 version |
| 14:59 | <Taggnostr> | gsnedders, that's normal, 2to3 leaves many ambiguos things (like str/unicode) untouched |
| 15:01 | <zewt> | why am I continually surprised by the stupid things people do on the web? |
| 15:02 | <zewt> | this utility autopay setup form first prevents me from pasting my routing/account number, then makes me enter it twice (since hey, you can't paste it, so you're likely to make an error!) |
| 15:09 | <Taggnostr> | it's just saving you from computer-made copy errors and/or buggy clipboards |
| 15:19 | <jgraham> | Taggnostr: I don't think porting html5lib to Python 3 would be that much work, but there are a few non-trivial issues |
| 15:19 | <jgraham> | mostly related to encoding ofc |
| 15:32 | <StoneCypher> | When I write pixels to a <canvas>' imageData, they display as expected. When I try to read them back, the whole buffer is 0. Am I missing something? Do I need to write the imageData to the context then make a new one, or something? |
| 15:33 | <Philip`> | StoneCypher: How are you trying to read them back? |
| 15:33 | <StoneCypher> | var r1 = imageData.data[index+0]; // etc |
| 15:33 | <Philip`> | Where are you getting that imageData object from? |
| 15:33 | <StoneCypher> | imageData = tgtContext.createImageData(uWidth, uHeight); |
| 15:33 | <StoneCypher> | tgtContext = tgtCanvas.getContext('2d'); |
| 15:33 | <StoneCypher> | those are out of order |
| 15:34 | <StoneCypher> | the imageData.data buffer is the right size |
| 15:34 | <StoneCypher> | it's just all zeroes, instead of the stuff that's actually on screen |
| 15:34 | <Philip`> | createImageData is for creating an empty ImageData object (so you can fill in its content then putImageData it) |
| 15:34 | <StoneCypher> | oh |
| 15:34 | <Philip`> | If you want to initialise it with the current canvas content, you have to use getImageData |
| 15:34 | <StoneCypher> | oh :) |
| 15:35 | <Philip`> | (and it makes a copy of the data, it's not a live view) |
| 15:35 | <Philip`> | (so do getImageData after all your drawing) |
| 15:35 | <StoneCypher> | ok cool |
| 15:35 | StoneCypher | had tried that, but with create, as a possibility already, so |
| 15:35 | <StoneCypher> | that should be straightforward, sec |
| 15:38 | <StoneCypher> | hooray! |
| 15:38 | <StoneCypher> | thank you :) |
| 15:39 | <StoneCypher> | and now on to fixing bugs i understand. |
| 16:07 | <StoneCypher> | Philip`: do you know a way to get .getImageData to include the color of the tag's background, or do i need to switch to setting that in the pixel data instead |
| 16:08 | <StoneCypher> | oh, maybe context.globalCompositeOperation = "destination-over"; |
| 16:10 | <StoneCypher> | nope. |
| 16:11 | <StoneCypher> | hell with it, i'll just set it in the pixel data |
| 16:28 | <Philip`> | StoneCypher: By "the tag's background", do you mean the colour that shows through when the image data in the canvas is transparent? |
| 17:00 | <Taggnostr> | jgraham, do you think a gsoc project is too much for that? |
| 17:16 | <joancreus> | hmm. what's the general opinion on a new kind-of standard, a "navigational API". it should allow to unify site links. it could allow to format each entry (i.e. apply CSS) in PCs/laptops, but it could also be used to create custom context menus (i.e. next to Firefox button, a Wikipedia button) and also, for mobile phones, create websites which can make use of the "navigation" button (the... |
| 17:16 | <joancreus> | ...usual interface to get to different options) |
| 17:24 | <webben> | joancreus: Not sure I get it. What user problem are you trying to solve? Does @rel not solve it? |
| 17:25 | <joancreus> | webben: navigation in mobile phones , basically |
| 17:25 | <joancreus> | it's a mess. in a PC, you got it at the top, or in the sides |
| 17:25 | <joancreus> | with mobile phones, you got it either on top, or on bottom |
| 17:25 | <joancreus> | what i suggest is that mobile phones should implement |
| 17:25 | <joancreus> | that when clicking the nav button on the phone, the links appear |
| 17:26 | <joancreus> | pc browsers could implement similar things, or keep nav links as they are, or adding a menu item for the website |
| 17:26 | <webben> | joancreus: sounds like a problem that can be solved by mobile ua's using <nav> to identity navigation links and putting them wherever they want |
| 17:27 | <webben> | joancreus: in practice the current trend seems to be for mobile UAs to mimic the presentation familiar to users from desktop UAs so they may not be inc;ined to use <nav> that way tho |
| 17:27 | <joancreus> | hmm but do mobile browsers implement such a thing? it'd be great |
| 17:27 | <joancreus> | webben: regarding what i said, imagine the wikipedia homepage |
| 17:27 | <joancreus> | there are a ton of links on the sidebar |
| 17:28 | <joancreus> | which could be grouped semantically (even inside nav); mobile browsers could implement what i was saying |
| 17:28 | <joancreus> | anyway, never mind, just random thoughts |