| 00:00 | <zewt> | heh, nothing's quite as much fun as pages that disable submit buttons, then reloading it and having it stay disables |
| 00:00 | <zewt> | i use GM scripts to disable that nonsense on a page or two |
| 00:03 | <smaug____> | Hixie: are you using any script libraries (which may do random stuff) |
| 00:43 | <Hixie> | bummer, he left |
| 00:43 | <Hixie> | no script libraries |
| 04:40 | <kennyluck> | hmm… didn't notice that IE and FF aren't doing the UTF8 with error handling fully, e.g. for error happening at the end of streams. |
| 10:58 | <annevk> | kennyluck: end of stream is a drama all over the place |
| 12:34 | <Ms2ger> | http://webbeep.it/spec.html |
| 12:36 | <erlehmann> | Ms2ger, better https://github.com/erlehmann/libglitch/blob/master/FORMAT-draft-erlehmann |
| 12:38 | <erlehmann> | Ms2ger, web beeps is probably very useful for 90ies hacker movies |
| 12:39 | <erlehmann> | >By restricting these to a pentatonic scale, arbitrary combinations of notes could be used without major dissonance. |
| 12:39 | <erlehmann> | clever |
| 13:19 | Philip` | always likes diagrams with spellchecker underlines in them |
| 15:05 | <annevk> | what's a good name for the encoding data table / mapping table / thingie? |
| 15:05 | <annevk> | index? mapping? |
| 15:06 | <annevk> | naming sucks |
| 15:08 | <Philip`> | Lookup table? |
| 15:09 | <annevk> | and URL lookup-table-iso-8859-2.txt ? |
| 15:15 | <zewt> | simply "map"? |
| 15:17 | <annevk> | "an encoding can have map" |
| 15:18 | <zewt> | ? |
| 15:18 | <zewt> | "can have a map" |
| 15:19 | <annevk> | euh yeah |
| 15:19 | <annevk> | although some can have more than one I suppose |
| 15:36 | <Ms2ger> | Almost a year since Google announced they were dropping support for H.264 |
| 15:38 | <izhak> | The lack of a good modular html parser implementation on c/c++ is really really oppressive. |
| 15:39 | <izhak> | As the DOM C/C++ implementaion lack is. |
| 15:39 | <annevk> | so fix it :) |
| 15:41 | <izhak> | annevk: I'm trying:) |
| 15:41 | <izhak> | Lot's of people trying I suppose. |
| 15:42 | <annevk> | I haven't seen much actually apart from browser implementations and implementations in JavaScript |
| 15:42 | <izhak> | Well, trying never meant success. |
| 15:43 | <izhak> | I think the next step in Web is not possible without having bringing modularity to scene |
| 15:50 | <Philip`> | izhak: What do you consider "modular" to be? |
| 15:51 | <Philip`> | (e.g. is the parser okay if it forces you to use its own DOM implementation?) |
| 15:53 | Philip` | isn't about to suggest an implementation, he's just curious as to what's desired |
| 15:54 | <izhak> | Philip`: By modular I mean particular parts of browsers to be done as libraries with stable interfaces |
| 15:54 | <izhak> | Say, DOM, HTML forgiving parser |
| 15:57 | <Philip`> | Parsers in browsers have to support scripting (and document.write etc) which I imagine makes the interfaces far more complex and messy - would it be better to just have a non-scripting parser with a simpler API? |
| 15:57 | <izhak> | UI and Object Model diversion |
| 15:58 | <Philip`> | (A non-scripting parser would be useless when implementing a parser, but is presumably what's needed for almost every other instance of HTML parsing) |
| 15:58 | <Philip`> | s/implementing a parser/implementing a browser/ |
| 15:58 | <annevk> | Ms2ger: I'm going to retire the unicode- files I generated earlier in favor of these new files |
| 15:58 | <Ms2ger> | Alright |
| 15:58 | <izhak> | non-script parser becomes more and more useless today |
| 16:00 | <izhak> | As I know even crowlers (why even? - neatly) run scripts today |
| 16:02 | <smaug____> | and since you need scripting, designing api for modular parser is hard |
| 16:02 | <smaug____> | If you need a C++ parser, I'd take hsivonen's parser and translate it to C++ |
| 16:03 | <smaug____> | (using some automatic tool) |
| 16:09 | <webben> | Philip`: scripting parsers are likely better for a lot of scraping applications. |
| 16:09 | <Philip`> | izhak: It wouldn't be feasible for them to run scripts without implementing pretty much an entire web browser (in which case they'd presumably automate a WebKit instead of writing their own code) |
| 16:10 | <webben> | yes, hence ChromeDriver and Phantom.JS. |
| 16:10 | <webben> | *PhantomJS |
| 16:10 | <Philip`> | izhak: (In my testing some time ago, Googlebot dealt with scripts just by looking inside the script text for strings that looked like absolute or relative URLs and then crawling those, without attempting to actually run any scripts) |
| 16:11 | <Philip`> | (and a non-scripting parser should be sufficient for that) |
| 16:12 | <izhak> | Philip`: That's the issue of UI and Object Model mess |
| 16:12 | <izhak> | They should be decoupled |
| 16:12 | <izhak> | Just parsing out the links from scripts is not sufficient |
| 16:16 | <Philip`> | We can't do anything about the layering-violation mess that browsers have to deal with, so I think my hypothetical question is whether there'd be more interest in a necessarily messy API that can deal with that mess, or a nice clean modular API that ignores it but is probably still good enough for any use case that doesn't involve building an entire browser |
| 16:21 | <izhak> | The semantics which is expected to be found on Web in an increasing quantity and quality requires an access to the API of different layers today, opposite to the Past when only the resulted web page was an object of interest. |
| 16:22 | <izhak> | So the clean API to that modules I think will be demanded more and more |
| 16:54 | <annevk> | Ms2ger: http://dvcs.w3.org/hg/encoding/raw-file/tip/map-iso-8859-3.txt |
| 16:55 | <Ms2ger> | Nice, thanks |
| 16:55 | <annevk> | since most of section 5 is non-normative now maybe that should be nuked, but it's somewhat valuable I guess |
| 16:56 | <annevk> | well you can always look at http://dvcs.w3.org/hg/encoding/raw-file/tip/single-octet-research.html I suppose |
| 17:10 | <annevk> | any objections to removing 5.1 - 5.28? |
| 17:28 | <annevk> | done |
| 17:33 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html |
| 17:44 | <annevk> | I never realized the only multi-octet encodings were from CJK |
| 17:52 | <annevk> | """ |
| 17:52 | <annevk> | And here's the table they used: |
| 17:52 | <annevk> | Big5 to Unicode(codepoint): |
| 17:52 | <annevk> | http://moztw.org/docs/big5/table/moz18-b2u.txt |
| 17:52 | <annevk> | Unicode(codepoint) to Big5: |
| 17:52 | <annevk> | http://moztw.org/docs/big5/table/moz18-u2b.txt |
| 17:52 | <annevk> | """ |
| 17:52 | <annevk> | the second file has more lines than the first... |
| 17:59 | <annevk> | smaug____: btw, before you get surprised, WebKit does not default whatToShow to SHOW_ALL; since WebKit's default was 0 we decided on a better one |
| 19:04 | <annevk> | so Chrome still understands a fair bit of iso-2022-cn (which is btw another hopeless mess), it just doesn't use any data tables for it |
| 19:11 | <bga_> | gsnedders are you here? |
| 19:14 | <gsnedders> | bga_: yes |
| 19:14 | <bga_> | . /([@!])(.*?)$/.exec('12@1@!12@3') |
| 19:14 | <gsnedders> | Known bug. |
| 19:15 | <bga_> | i want non gredy backward search |
| 19:15 | <gsnedders> | I think. |
| 19:15 | <gsnedders> | If that's what I think. |
| 19:15 | <gsnedders> | Oh, wait, no it isn't. |
| 19:15 | <bga_> | but its greedy |
| 19:15 | <gsnedders> | bga_: So the last @ or ! and everything that follows? |
| 19:16 | <bga_> | yeah |
| 19:16 | <bga_> | last, not first |
| 19:17 | <gsnedders> | /(@[^@]*|![^!]*)$/ will be quicker than anything more complex. |
| 19:17 | <bga_> | hm |
| 19:18 | <bga_> | . /(.)([^@!]*?)$/.exec('12@1@!12@3') |
| 19:18 | <bga_> | thanks |
| 19:18 | <bga_> | not general solution but works |
| 19:19 | <gsnedders> | Not sure why that isn't greedy off hand. |
| 19:19 | <gsnedders> | Oh, duh |
| 19:19 | <bga_> | i reversed string before and it worked too, but full string reverse is slow |
| 19:20 | <gsnedders> | It matches the [@!] first. Then it backtracks when it has to for the .* |
| 19:20 | <gsnedders> | But it never has to backtrack for that, as everything matches it and the following $. |
| 19:23 | <erlehmann> | i wonder why people do that https://plus.google.com/105786194532858868645/posts |
| 19:24 | <erlehmann> | after all the chrome team has repeatedly shown they do hate the open web |
| 19:24 | <erlehmann> | err |
| 19:24 | <erlehmann> | the google+ team |
| 19:24 | <erlehmann> | i am of sleepy today |
| 19:24 | <erlehmann> | sorry to the chrome team ;) |
| 19:24 | <gsnedders> | Yeah, I should go get a more modern browser for Google+. |
| 19:25 | <erlehmann> | gsnedders, when you use opera, do they show an upgrade message? |
| 20:08 | <gsnedders> | erlehmann: Certainly I've seen it several times, yeah |
| 20:08 | <erlehmann> | gsnedders, you better do no evil … or else! |
| 20:09 | <erlehmann> | „evil“ meaning running a non-approved browser ^_^ |
| 20:09 | <gsnedders> | Well, Opera is finally slowly getting into Google's automated testing |
| 20:12 | <smaug____> | (It feels to me that Google is testing stuff more and more only using Chrome) |
| 22:01 | <GPHemsley> | annevk: Are you aware that the '**' and 'Issue:' overlap in your Encoding files (and others?)? |
| 22:02 | <zewt> | what the |
| 22:02 | <zewt> | cool, chrome is crashing on initial load, heh |
| 22:03 | <zewt> | wonder if they pushed a bad update or something |
| 22:07 | <annevk> | GPHemsley: ooh, I guess that's because of the WHATWG style sheet |
| 22:10 | <annevk> | GPHemsley: fixed for http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html |
| 22:10 | <GPHemsley> | cool |
| 22:11 | <GPHemsley> | annevk: Oh, you just removed the 'Issue' part? |
| 22:11 | <annevk> | euh yeah? |
| 22:11 | <GPHemsley> | because apparently they were marking two different things |
| 22:11 | <GPHemsley> | (not everything had both) |
| 22:12 | <annevk> | oh that's because I only applied Issue: to <p> |
| 22:12 | <annevk> | and not <ol> |
| 22:12 | <annevk> | but it's all the same |
| 22:12 | <GPHemsley> | ah, OK |
| 22:12 | <annevk> | something that needs better text (or text at all) |
| 22:12 | <GPHemsley> | right |
| 22:33 | <annevk> | so are we back to no longer discussing new features on some list? https://bugzilla.mozilla.org/show_bug.cgi?id=697132 |
| 22:39 | <smaug____> | annevk: that is mainly about the b2g thing |
| 22:40 | <smaug____> | so, very experimental stuff atm |
| 22:40 | <bga_> | hm |
| 22:40 | <bga_> | document.elementFromPoint({x: 0, y: 0}) |
| 22:40 | <bga_> | is it standard feature? |
| 22:41 | <smaug____> | elementFromPoint is, but the parameter isn't |
| 22:41 | <bga_> | but chrome support object :) |
| 22:41 | <bga_> | ok |
| 22:41 | <bga_> | thanks |
| 22:42 | <smaug____> | huh |
| 22:45 | <bga_> | also |
| 22:46 | <bga_> | style.width = '1m' |
| 22:46 | <bga_> | is it meter or mile? |
| 22:46 | <zewt> | one light minute |
| 22:47 | <bga_> | chome gives me 968px in offsetWidth |
| 22:47 | <bga_> | but if i calc 100cm - its 3700px |
| 22:48 | <bga_> | hm |