| 08:31 | <krijnh> | (sorry for downtime) |
| 08:32 | <annevk2> | I assume you worked on adding a hundred new cool features? :p |
| 08:41 | <zcorpan> | good morning guys |
| 08:44 | <wilhelm> | 'Morning. (c: |
| 09:46 | <zcorpan> | hmm. <h1><p><span><h1> |
| 09:46 | <zcorpan> | should the h1 be nested or not |
| 09:49 | <zcorpan> | webkit now nests <p><font><h1>x |
| 11:57 | <hsivonen> | Hixie: seen this? https://bugzilla.mozilla.org/show_bug.cgi?id=459395 |
| 12:02 | <hsivonen> | http://twitter.com/redwall_hp/statuses/957115107 |
| 12:09 | <Lachy> | LOL. I wonder what made him thing XFrames is part of the HTML5 work |
| 13:50 | <hsivonen> | yay. a new standards suck episode |
| 15:15 | <Lachy> | http://tech.slashdot.org/comments.pl?sid=993341&cid=25353353 |
| 15:20 | <ehird> | Lachy: That's slightly ridiculous. |
| 15:20 | <ehird> | Just about -nothing- supports <video> presently. |
| 15:20 | <ehird> | (Also, google have a vested interest in adding petty, easily-breakable barriers to downloading: because the big megacorps want to feel safe.) |
| 15:24 | <Lachy> | ehird, yeah, right now, the suggestion isn't realistic. But give it a few years, when browsers have actually shipped with support for <video> and the codec issue has settled a bit, they could begin migrating to it |
| 15:24 | <ehird> | Lachy: You're forgetting about IE. |
| 15:25 | <ehird> | (Which I commend you for - I wish I could.) |
| 15:25 | <ehird> | Lachy: Even so, see my last line. |
| 15:28 | <Philip`> | It's interesting to see the lengths the BBC iPlayer has gone to to prevent people downloading the iPhone-compatible MPEG4 versions of programmes on anything other than an iPhone, with strict checks on the exact sequence of HTTP requests made |
| 15:28 | <Lachy> | ehird, which "last line" are you referring to? |
| 15:29 | <Philip`> | but then they seem to have given up months ago |
| 15:29 | <ehird> | <ehird> (Also, google have a vested interest in adding petty, easily-breakable barriers to downloading: because the big megacorps want to feel safe.) |
| 15:29 | <Philip`> | and you can find plenty of simple scripts that you can give a URL and it'll download the MPEG4 onto your PC |
| 15:29 | <ehird> | Of course. |
| 15:29 | <hsivonen> | I wonder what the YouTube attitude towards old versions of Flash Player is |
| 15:29 | <Philip`> | so their protection has totally failed |
| 15:29 | <ehird> | But as long as they have stupid checks that mean nothing, the feeling of safety is given to those who request it. |
| 15:29 | <ehird> | If you see what I mean. |
| 15:29 | <Lachy> | ehird, since the megacorps don't own most of the content on YouTube, despite what some of them might like to claim, I find that difficult to believe |
| 15:30 | <hsivonen> | that is, do they feel that they need to support old versions that have security holes |
| 15:30 | <ehird> | Lachy: I'm talking about the recent collaborations with them. |
| 15:30 | <gpy> | is <br/> underestimated? |
| 15:32 | <Lachy> | I wonder where I can find those CBS videos on YouTube, and if they're available outside the USA? |
| 15:33 | <ehird> | Lachy: As for the latter half: unlikely. |
| 15:33 | <Lachy> | http://www.youtube.com/blog?entry=F1xABdzKby4 |
| 15:33 | <Lachy> | nope, they're not available in Norway at least |
| 15:33 | <ehird> | *shrug* Media sucks. I'm sure we all know this... |
| 15:34 | <Lachy> | which sucks, especially given that the shows they've started with are really old |
| 15:34 | <ehird> | Not accessible in the UK, either. |
| 15:34 | <Lachy> | it's not like they're shows which have yet to air in other countries |
| 15:34 | <ehird> | Lachy: YouTube probably couldn't afford the extra cash for extra country licenses or whatever other rubbish CBS forced on them |
| 15:35 | <ehird> | [[You may see in-stream video ads (including pre-, mid- and post-rolls) embedded in some of these episodes; this advertising format will only appear on premium content where you are most comfortable seeing such ads. In order to make this clear to you, we've labeled all full-length videos with a Film Strip symbol ( ) so you'll know exactly what kind of content you're choosing to watch and what ads you might see. (To see an example of the badge on search results, |
| 15:35 | <Lachy> | I'll see if I can bypass the regional lockout... |
| 15:35 | <ehird> | Ha. Ha. Ads! Wonderful! |
| 15:35 | <ehird> | Lachy: Hulu is easily bypassable, iirc, so I imagine this is too. |
| 15:36 | <Philip`> | CBS might have exclusive distribution licences with people in other countries, and be unable to let YouTube distribute things worldwide |
| 15:36 | <ehird> | Ahhh. That seems most likely. |
| 15:37 | Philip` | noticed a while ago that Comedy Central seems to block access from the UK specifically, rather than permitting specific countries, which seems slightly odd |
| 15:39 | <Philip`> | Ah, right, that's just because Channel 4 now shows their shows in the UK |
| 15:39 | <hsivonen> | territory-scoped media distribution deals are so last century |
| 15:40 | <Lachy> | sweet, I've successfully bypassed the regional restrictions |
| 15:40 | <Lachy> | :-) |
| 15:40 | <Lachy> | using ssh tunnelling through a server in the US |
| 15:42 | <Lachy> | hsivonen, pretty much all deals made by large media companies these days are using last centuries business models |
| 15:42 | hsivonen | is still wondering if the iTunes Movie Rental "international later this year" ends up meaning a couple of English-language countries |
| 15:43 | <ehird> | <Lachy> hsivonen, pretty much all deals made by large media companies these days are using last centuries business models |
| 15:43 | <ehird> | Truth! |
| 15:43 | <Philip`> | Lachy: Doesn't that mean they're this century's business models too? |
| 15:43 | <ehird> | Philip`: No, because people are starting to get a clue and evolving them. |
| 15:45 | <Lachy> | no, I mean they're business models designed for last century's technology and distribution networks, being brutally applied to this century's |
| 15:46 | <annevk3> | hsivonen, the Wii has Flash Player 7 |
| 15:47 | <hsivonen> | annevk3: that's unfortunate |
| 15:47 | <annevk3> | YouTube works fine on the Wii |
| 15:47 | <gsnedders> | greetings from France! |
| 15:47 | <hsivonen> | gsnedders: starting TPAC early? :-) |
| 15:48 | <gsnedders> | hsivonen: With my uncle for the week before |
| 15:48 | <ehird> | Proposal: HTML5 is said to be productionready along with a new standard of "Media Business Practices 21" :D |
| 16:00 | <takkaria> | Philip`: oh, I wasn't aware it was so trivially easy to get around the iplayer stuff. useful, that |
| 16:00 | gsnedders | wonders why one or two phone numbers won't sync on to his phone |
| 16:23 | <gsnedders> | Ergh. Need to write a second personal statement for Cambridge. |
| 16:35 | gsnedders | updates <http://stuff.gsnedders.com/http-parsing.html>; for the first time in ages |
| 16:36 | <gsnedders> | (Only section 3 and the to-do list has been touched) |
| 16:38 | <gsnedders> | Interestingly, behaviour varies a lot for one or two things |
| 16:39 | <gsnedders> | HTTP/1.1 12 Foobar |
| 16:39 | <gsnedders> | How should that be treated? |
| 16:40 | <gsnedders> | Saf/Leopard treats it as an invalid HTTP/1.1 response, and treats it as HTTP/0.9 (i.e., it is all data, no headers) |
| 16:41 | <gsnedders> | Firefox treats it as 12 |
| 16:42 | <gsnedders> | So does Opera |
| 16:42 | <gsnedders> | Even more varied over HTTP/1.1 1234 Foobar |
| 16:42 | <gsnedders> | Saf/Leopard again invalid |
| 16:43 | <gsnedders> | Firefox status-code: 1234 reason-phrase: "Foobar" |
| 16:43 | <gsnedders> | Op: status-code: "123", reason-phrase: "4 Foobar" |
| 16:44 | <gsnedders> | IE follows Fx |
| 16:44 | <gsnedders> | (or, more likely, Fx follows IE) |
| 16:45 | <gsnedders> | (and both probably follow NN) |
| 16:45 | <gsnedders> | IE, Op and Fx all use null-terminated strings for header values |
| 16:46 | <gsnedders> | With no reason-phrase given, IE defaults to "Close" |
| 16:46 | <gsnedders> | Which I guess it uses as the next thing after any *LWS |
| 16:48 | <gsnedders> | IE uses a list of headers that can be concatenated with ", ", everything else uses a list of headers to only use the first of |
| 18:10 | <gsnedders> | Anyone in France with a Freebox around? |
| 18:11 | gsnedders | needs to get the wifi password somehow |
| 18:21 | <gsnedders> | Yay! Got password! It works! |
| 19:12 | <annevk3> | ah, so Dion did leave Google... somehow that was not entirely clear to me after watching the video on ajaxian.com |
| 20:11 | <gsnedders> | Ergh: |
| 20:11 | <gsnedders> | The photograph should: |
| 20:11 | <gsnedders> | be in portrait orientation (with a height to width ratio of 6:5) |
| 20:11 | <gsnedders> | be in colour |
| 20:11 | <gsnedders> | have a plain light coloured background |
| 20:11 | <gsnedders> | show your head and the top of your shoulders only, with your face central on the picture |
| 20:11 | <gsnedders> | be of good colour definition, not too dark or light |
| 20:11 | <gsnedders> | be in focus |
| 20:12 | <gsnedders> | show your face un-obscured (no sunglasses, hat or scarf) unless you wear glasses or cover your hair for religious reasons |
| 20:12 | <gsnedders> | show you acting naturally, not smoking, not with other people or in a 'holiday snap' |
| 20:12 | <gsnedders> | I don't think I have any that meet that description |
| 20:12 | <gsnedders> | Or at least, any with me with long-ish hair |
| 20:36 | <krijnh> | annevk3: sorry, not really :) |
| 20:39 | <gsnedders> | Lachy: I'm going to have a book we were talking about a few months back at TPAC :) |
| 21:08 | <gsnedders> | Is it just me or will the video on <http://standardssuck.org/w3c-standardization-process>; not load? |
| 21:18 | <gsnedders> | I need to get a real macro lens |
| 21:32 | <Philip`> | gsnedders: It's not just you, since it says "Plug-in content" to me, but that's not surprising since I don't have any working plugins |
| 21:32 | <gsnedders> | :P |
| 21:48 | <erlehmann> | had they used <video> |
| 21:49 | <gsnedders> | My browser wouldn't support it at all :) |
| 21:50 | <Philip`> | Just link to an MPEG4 download - it's really not that hard :-p |
| 22:08 | <roc> | so tell me what you need |
| 22:09 | <onitunes> | http://developer.apple.com/documentation/Carbon/Conceptual/CoreText_Programming/Overview/chapter_2_section_5.html#//apple_ref/doc/uid/TP40005533-CH3-DontLinkElementID_14 |
| 22:09 | <onitunes> | that's basically the API I'm using on the desktop |
| 22:09 | <onitunes> | I'm building an in-browser IDE with SproutCore |
| 22:09 | <onitunes> | but I have to do all of the text manipulation on the server, because the client-side APIs aren't there yet |
| 22:10 | <onitunes> | I basically have a grip of span tags with one character each |
| 22:10 | <onitunes> | that fill up the visible area in a scrollable div |
| 22:10 | <olliej> | onitunes: are you sure this is really a task that is suitable to canvas? |
| 22:10 | <onitunes> | and as the user scrolls, I update the innerText and span classes to syntax highlight correctly |
| 22:11 | <onitunes> | to handle text selection, I have a <canvas> tag overlayed and I forward the mouse down to the server, get the results back, and update drawing |
| 22:11 | <roc> | if you're building a text editor, we probably want to find a way to make contenteditable do what you need |
| 22:11 | <onitunes> | sorry, this is not HTML |
| 22:11 | <onitunes> | that whole API sucks |
| 22:11 | <onitunes> | it's like FrontPage for the browser |
| 22:11 | <onitunes> | :P |
| 22:11 | <onitunes> | which is the real problem |
| 22:12 | <onitunes> | you guys are writing for HTML people |
| 22:12 | <onitunes> | I just want to display text |
| 22:12 | <olliej> | onitunes: so your solution is to complain about a bitmap api rather than make suggestions for improving contenteditable? |
| 22:12 | <onitunes> | and basically, I'm working around the browser to get it to do that |
| 22:12 | <roc> | you really want the browser to understand that you're editing text |
| 22:12 | <onitunes> | who's complaining? |
| 22:12 | <roc> | otherwise stuff like IMEs won't work |
| 22:13 | <onitunes> | I just think it's incredible that text layout metrics are not available in the browser |
| 22:13 | <roc> | I would like to make them available in the browser, but it's complicated because of issues like font selection |
| 22:13 | <onitunes> | not anyone's fault, and I'm happy to patch <canvas> to add support for the 5 Core Text objects- |
| 22:13 | <onitunes> | really, this is not a big API |
| 22:14 | <onitunes> | anyway, I can do what I'm doing now, because I always have a server |
| 22:14 | <roc> | Core Text is much more than exposing text layout metrics |
| 22:14 | <onitunes> | agreed |
| 22:14 | <onitunes> | but it's pretty fundamental |
| 22:14 | <onitunes> | stuff |
| 22:15 | <onitunes> | I would expect JavaScript library authors to wrap it and provide a higher-level API |
| 22:15 | <onitunes> | but today, we have to wrap even higher-level APIs |
| 22:15 | <onitunes> | to do things they were never meant to do |
| 22:16 | <onitunes> | and do inefficiently at that |
| 22:16 | <roc> | that approach will never work with IMEs so it's simply not the right way to go |
| 22:16 | <olliej> | onitunes: your approach will not work with IME's. It just won't be possible |
| 22:16 | <onitunes> | ? |
| 22:16 | <olliej> | roc: :P |
| 22:16 | <onitunes> | what does IME have to do with this? |
| 22:16 | <olliej> | onitunes: international input |
| 22:16 | <onitunes> | yes, I know what it is |
| 22:16 | <Hixie> | if you're writing a text editor, you're going to have to use contenteditable or textarea or input type=text, otherwise you won't be accessible to things like voice browsers or other non-graphical user agents |
| 22:16 | <onitunes> | this has *nothing* to do with text input |
| 22:17 | <roc> | you said you were writing an IDE, I assumed this was about text editing |
| 22:17 | <onitunes> | Hixie: I already do the textarea thing |
| 22:17 | <Hixie> | ok |
| 22:17 | <onitunes> | but it's dumb |
| 22:17 | <onitunes> | just there to grab keystrokes |
| 22:17 | <roc> | maybe you should explain your requirements instead of just telling us what we shoud do |
| 22:17 | <onitunes> | which I forward on to a server |
| 22:17 | <Hixie> | so what is it you are trying to do? |
| 22:17 | <onitunes> | roc: I never said anyone should do aynthing |
| 22:17 | <onitunes> | I asked about submitting a patch |
| 22:18 | <onitunes> | Hixie: I want to be able to render an attributed string inside a <canvas> like tag, with functionality equivalent to that exposed by Core Text on Mac OS X |
| 22:18 | Philip` | would hope browser developers wouldn't accept patches if they didn't know what you were trying to do which needed that patch |
| 22:18 | <roc> | tell us what you're trying to achieve, not how you think you should do it |
| 22:18 | <olliej> | Philip`: we wouldn't |
| 22:18 | <Hixie> | onitunes: why? |
| 22:19 | <Hixie> | onitunes: what are you trying to do? |
| 22:19 | <onitunes> | :/ |
| 22:19 | <Hixie> | note that even if you wrote a patch for mozilla and webkit, you can't do that for microsoft and opera, so at some level you're asking for the spec to change and for the browsers to implement something, so we need to understand what you want and why :-) |
| 22:19 | <onitunes> | let me turn this around then |
| 22:20 | <onitunes> | why does Apple provide developers with Core Text? |
| 22:20 | <olliej> | onitunes: just tell us what you want |
| 22:20 | <olliej> | to do |
| 22:20 | <olliej> | onitunes: why is that so hard |
| 22:20 | <onitunes> | what am I, some Noob who just needs to learn the API? |
| 22:20 | <onitunes> | I already did that |
| 22:20 | <onitunes> | "I want to be able to render an attributed string inside a <canvas> like tag, with functionality equivalent to that exposed by Core Text on Mac OS X" |
| 22:20 | <Hixie> | why? |
| 22:20 | <onitunes> | why does that matter |
| 22:20 | <onitunes> | seriously |
| 22:20 | <roc> | even if he wrote a patch for Mozilla, we aren't just going to take it unless we agree it's a necessary and good API. Taking patches is not free |
| 22:20 | <Hixie> | because we design APIs to address use cases |
| 22:21 | <olliej> | onitunes: because there might be a better way to do it |
| 22:21 | <olliej> | onitunes: supporting hacks is not the task of a standard -- we want sensible solutions to general problems |
| 22:21 | <onitunes> | that's exactly what Core Text is |
| 22:21 | olliej | face palms |
| 22:22 | olliej | goes off to do something productive |
| 22:22 | <onitunes> | "The Core Text framework is an advanced, low-level technology for laying out text and handling fonts." |
| 22:22 | <Hixie> | CSS is an advanced, low-level technology for laying out text and handling fonts. |
| 22:22 | <Hixie> | maybe you should use CSS? |
| 22:22 | <onitunes> | jeez |
| 22:22 | <Hixie> | it's hard to know what you actually need if you won't tell us :-) |
| 22:22 | <onitunes> | I do, it sucks |
| 22:22 | <roc> | onitunes: you've got key people for three different projects all giving you attention, and you've squandered it |
| 22:22 | <onitunes> | I don't understand why you guys get to decide what I "need" |
| 22:23 | <onitunes> | I fail to see how |
| 22:23 | <onitunes> | I said *exactly* what I wanted, and why |
| 22:23 | <Philip`> | onitunes: We're asking what you need, not telling you what you need |
| 22:23 | <onitunes> | I need to be able to lay out styled text within a <canvas> like tag |
| 22:23 | <Hixie> | why? |
| 22:23 | <onitunes> | using a programmatic, not DOM-oriented API |
| 22:24 | <onitunes> | because that's what text layout applications do |
| 22:24 | <onitunes> | and text editors are, in part, text layout applications |
| 22:24 | <Hixie> | what is a "text layout application"? |
| 22:24 | <onitunes> | TextMate |
| 22:24 | <onitunes> | Emacs |
| 22:24 | <onitunes> | vi |
| 22:24 | <onitunes> | terminals |
| 22:24 | <onitunes> | Adobe InDesign |
| 22:25 | <Hixie> | text editors are intended to be addressed by contentEditable and CSS; what is it about contentEditable and CSS that can't replicate the functionality of TextMate, Emacs, vi, terminals, InDesign, etc? |
| 22:25 | <onitunes> | they are DOM-oriented |
| 22:25 | <Hixie> | right, that's a feature |
| 22:25 | <onitunes> | for me, it's a bug |
| 22:25 | <onitunes> | I'm not creating HTML |
| 22:25 | <Hixie> | why? |
| 22:25 | <onitunes> | so I have to extract out the text from the HTML |
| 22:25 | <Hixie> | what are you creating? |
| 22:25 | <onitunes> | text |
| 22:26 | <onitunes> | have you seen the madness people have gone through trying to implement syntax highlighting in the browser? |
| 22:26 | <Hixie> | so what's wrong with using HTML? It's a text markup languae. |
| 22:26 | <onitunes> | exactly |
| 22:26 | <onitunes> | MARKUP |
| 22:26 | <onitunes> | I'm not creating HTML |
| 22:26 | <onitunes> | or any other kind of markup |
| 22:26 | <onitunes> | I'm creating raw text, and styling it |
| 22:26 | <olliej> | eg. marking it up |
| 22:27 | onitunes | palms in hands |
| 22:27 | <olliej> | onitunes: have you tried node.innerText ? |
| 22:27 | <onitunes> | seriously? |
| 22:27 | <onitunes> | of course I have |
| 22:27 | <roc> | Daniel Glazman has implemented a general syntax highlighting package that works with the DOM and HTML |
| 22:27 | <Hixie> | i'm afraid i am not understanding your request. I encourage you to read our FAQ and post your feedback straight to the mailing list where I can give it a longer and more considered response when I have more time available. FAQ: http://wiki.whatwg.org/wiki/FAQ Mailing list: http://whatwg.org/mailing-list#specs |
| 22:28 | <olliej> | onitunes: you want to display styled content -- that means markup |
| 22:28 | <olliej> | onitunes: you don't have to save markup |
| 22:28 | <roc> | sure, contenteditable etc could be improved, and we'd welcome suggestions on how to do that, but without contenteditable you won't get IME support or accessibility, so your approach of reimplementing text editing from scratch is not the right way to go. |
| 22:28 | <onitunes> | hmm, styled text != markup |
| 22:29 | <onitunes> | I guess we'll just have to agree to disagree there |
| 22:29 | <olliej> | onitunes: yes it does, NSAttributedString (of which you seem so enamoured) is a string with markup |
| 22:29 | <roc> | (you also won't get the right platform-specific editor UI) |
| 22:29 | <onitunes> | of course it is |
| 22:29 | <onitunes> | but it's not DOM nodes |
| 22:29 | <onitunes> | which is what you're suggesting I use |
| 22:29 | <onitunes> | along with CSS |
| 22:29 | <Hixie> | do DOM nodes have cooties or something? |
| 22:30 | <olliej> | onitunes: yes, because you're in a browser |
| 22:30 | <onitunes> | then tell me this: why does <canvas> exist? |
| 22:30 | <onitunes> | why not SVG? |
| 22:30 | <olliej> | onitunes: you're asking for a non browser technology so that you can create an in browser ide -- do you not see the problem with this? |
| 22:30 | <Hixie> | onitunes: mostly to allow people to render platform games and fractals |
| 22:30 | <onitunes> | Hixie: then why not SVG? |
| 22:30 | <Hixie> | onitunes: or to draw graphs |
| 22:31 | <Hixie> | onitunes: you can't do fractals with SVG |
| 22:31 | <onitunes> | because retained-mode APIs are high-level |
| 22:31 | <Hixie> | no |
| 22:31 | <onitunes> | sometimes, you just want to paint |
| 22:31 | <Hixie> | canvas is as high-level as svg |
| 22:31 | <onitunes> | why we can't paint text is beyond me |
| 22:31 | <Hixie> | it's just for a different set of use cases |
| 22:31 | <Hixie> | you can paint text |
| 22:31 | <Hixie> | you just can't measure it very well :-) |
| 22:31 | <Hixie> | or paint it along a path or to a path |
| 22:32 | <onitunes> | why is there resistance to this? |
| 22:32 | <Hixie> | to what? |
| 22:32 | <onitunes> | low-level text rendering in a canvas tag |
| 22:32 | <Hixie> | canvas already has low-level text rendering |
| 22:33 | <onitunes> | without layout, it's not worth much |
| 22:33 | Dashiva | has bad memories of having to make a bitmap font for text rendering in canvas back in 2006 |
| 22:33 | <roc> | I explained clearly why your approach is not the right direction for text editing. |
| 22:33 | <Hixie> | it doesn't have metrics because it is as yet still early days and nobody has given a convincing problem they're trying to solve for which we need to expose text metrics |
| 22:33 | <onitunes> | roc: it's not for text editing |
| 22:33 | <Hixie> | so what is it for? |
| 22:33 | <onitunes> | text rendering |
| 22:33 | <onitunes> | Core Text has nothing to do with editing |
| 22:33 | <Hixie> | that's what CSS is for |
| 22:33 | <Hixie> | Core Text has nothing to do with the Web either :-) |
| 22:34 | <roc> | you have refused to tell us what it actually is for, so we have to guess |
| 22:34 | <onitunes> | the browser != the web |
| 22:34 | <onitunes> | and it does have something to do with the browser |
| 22:34 | <Hixie> | i'm not really sure what that means |
| 22:34 | <Hixie> | Core Text is a Mac OS specific technology |
| 22:34 | <Hixie> | it has little to do with browsers in general |
| 22:35 | <onitunes> | if you say so |
| 22:35 | <onitunes> | you could say the same about video and audio, but low and behold, there are <video> and <audio> tags |
| 22:35 | <onitunes> | my original question was: could we make a <text> tag |
| 22:35 | <Hixie> | video is not a Mac OS specific technology either :-) |
| 22:35 | <Hixie> | we have one |
| 22:35 | <onitunes> | that worked like <canvas>, but let you control layout |
| 22:36 | <Hixie> | we have two, in fact |
| 22:36 | <roc> | why don't you just tell us why HTML and CSS don't satisfy your needs |
| 22:36 | <roc> | if you can't do that, you're just wasting our time |
| 22:36 | <Hixie> | (namely, one in SVG (<text>), and one in HTML (<span>), both of which are styled with CSS) |
| 22:36 | <onitunes> | roc: incremental rendering |
| 22:37 | <onitunes> | with the DOM, you have to include everything in the DOM for it to lay things out for you |
| 22:37 | <roc> | good, be more specific |
| 22:37 | <onitunes> | a 1MB file cannot have the full DOM created and updated, with correct syntax highlighting, in realtime, on each key press |
| 22:38 | <onitunes> | to work around that, programmers cheat: |
| 22:38 | <onitunes> | they take a grid, say 400 characters wide by 400 characters tall |
| 22:38 | <onitunes> | and make each cell in the grid a <span> tag |
| 22:38 | <onitunes> | then the use node.innerText to update the character |
| 22:38 | <Hixie> | um, that is patently untrue. load the HTML5 spec in a browser and type javascript:document.body.contentEditable=true into the location bar |
| 22:38 | <onitunes> | and set the correct class on each tag |
| 22:38 | <Hixie> | pronto, a 2MB+ document editing in realtime |
| 22:39 | <onitunes> | contentEditible is for HTML |
| 22:39 | <Hixie> | yes |
| 22:39 | <onitunes> | I'm not editing HTMl |
| 22:39 | <onitunes> | I'm editing text |
| 22:39 | <Hixie> | why not? |
| 22:39 | <Hixie> | so mark your text up in HTML |
| 22:39 | <onitunes> | just raw, plain old syntax-highlight texd |
| 22:39 | <Hixie> | raw, plain old syntax-highlighted text is exactly what HTML is |
| 22:40 | <onitunes> | nonsense |
| 22:40 | <onitunes> | HTML is semantic |
| 22:40 | <Hixie> | what do you think syntax highlighting is if not semantics? |
| 22:40 | <onitunes> | and basically, to get interactive performance, I have to completely blow away those semanticns |
| 22:40 | <onitunes> | its identical to using tables for layout |
| 22:41 | <onitunes> | what I have to do with the DOM to syntax highlight source code |
| 22:41 | <onitunes> | I can do it, and I *do do it |
| 22:41 | <onitunes> | as in, it works |
| 22:41 | <roc> | if you're not using contenteditable, you're doing it wrong. |
| 22:41 | <onitunes> | but I would be much better off without the workaround, using DOM nodes for layout, when something like Core Text is what I would use on the desktop |
| 22:42 | <onitunes> | roc: okay |
| 22:42 | <onitunes> | contenteditable does not do incremental layout |
| 22:42 | <onitunes> | I need that |
| 22:42 | <roc> | yes it does |
| 22:42 | <onitunes> | well, it sounds like there's no interest in a low-level text API |
| 22:42 | <roc> | what it doesn't do is incremental recomputation of syntax highlighting |
| 22:42 | <onitunes> | I'll move on, we all have better things to do |
| 22:43 | <roc> | so there's this: http://www.disruptive-innovations.com/zoo/diavolo/diavolo.html |
| 22:43 | <onitunes> | yeah, it's DOM-centric |
| 22:43 | <annevk3> | onitunes, what do you mean with "incremental layout"? |
| 22:43 | <roc> | which does pure-JS syntax highlighting. it's a Firefox extension, but the approach could be ported to regular HTML, I think |
| 22:43 | <onitunes> | annevk3: not creating DOM nodes for content that is not currently visible |
| 22:43 | <roc> | you don't really need that |
| 22:43 | <onitunes> | roc: you may be right |
| 22:44 | <roc> | you just need contenteditable and the syntax highlighter to be fast |
| 22:44 | <annevk3> | onitunes, why shouldn't that optimization be up to the browser? |
| 22:44 | <onitunes> | because they're too slow |
| 22:44 | <onitunes> | we have lists with 10,000 rows that we can scroll in realtime with incremental rendering |
| 22:45 | <onitunes> | if only 30 rows are visibile, we create 30 DOM nodes and re-use them as the user scrolls, swapping their contents |
| 22:45 | <annevk3> | onitunes, so why not implement the "incremental layout" yourself? ah, you're doing that |
| 22:45 | <onitunes> | right, I do that now |
| 22:45 | <onitunes> | with <span> cells |
| 22:45 | <onitunes> | look, I can make this work today |
| 22:46 | <roc> | "I'm doing this and it's slow" is much more useful information than "you must support a Core Text API" |
| 22:46 | <onitunes> | but it would be much nicer not to have to trick the browser |
| 22:46 | <onitunes> | and to instead have a nice, low-level text rendering API like Core TExt |
| 22:46 | <onitunes> | roc: okay, sorry I didn't mention that earlier |
| 22:46 | <Hixie> | if what you want is a fast syntax-highlighted plain text editor, it seems like it would be much better to provide an API for <textarea> that allows that than doing anything with canvas. |
| 22:47 | <onitunes> | Hixie: that could be |
| 22:47 | <roc> | as we've repeatedly explained, writing your own text editing throws away a lot of important features, so it's not the right way to go. |
| 22:47 | <Hixie> | onitunes: that's why we were asking for what you were doing |
| 22:47 | <roc> | what Hixie said |
| 22:47 | <Hixie> | there has been some interest in providing <textarea> syntax-highlighting, maybe backed in a way similar to <datagrid> JS datasource mechanism |
| 22:47 | <Hixie> | I'm waiting for <datagrid> implementations before going there though |
| 22:48 | <roc> | right now I'm not sure whether the problems you have are because you have too much text for the browser to handle efficiently, or whether it's because a pure-JS syntax highlighter isn't fast enough for you |
| 22:48 | <othermaciej> | onitunes: writing a text editor using an API at the level of CoreText would not be a wise idea, even in a native app |
| 22:48 | <othermaciej> | (reading some scrollback) |
| 22:49 | <onitunes> | it's not a real problem, I'm just certain it would render faster if I didn't have to do 1600 node.innerText updates to render the text view |
| 22:49 | <roc> | so you're not using contenteditable |
| 22:49 | <roc> | ? |
| 22:49 | <othermaciej> | onitunes: nearly all apps developed by Apple that display text use either NSTextView or WebView |
| 22:49 | <onitunes> | othermaciej: of course they do |
| 22:49 | <othermaciej> | not CoreText directly |
| 22:49 | <othermaciej> | even Xcode |
| 22:49 | <onitunes> | that's what I would build on top of it |
| 22:49 | <onitunes> | :-) |
| 22:49 | <othermaciej> | and Dashcode |
| 22:50 | <othermaciej> | so I do not see why an IDE would specifically want a low-level text drawing API instead of a rich text editing API |
| 22:50 | <onitunes> | but asking browser vendors to implement NSTextView is asking too much |
| 22:50 | <onitunes> | Core Text is much easier to provide, and allows innovation on top of it |
| 22:50 | <othermaciej> | I would advise start with contentEditable and point out what is missing that you need |
| 22:50 | <Hixie> | browser vendors are much more likely to implement NSTextView than CoreText at this point, frankly |
| 22:50 | <onitunes> | I've already said the problem with it: you have to construct the entire DOM tree |
| 22:50 | <onitunes> | Hixie: that's too bad |
| 22:50 | <othermaciej> | and is that technologically infeasible? |
| 22:51 | <annevk3> | it's slow |
| 22:51 | <onitunes> | performance-wise, it's a non-starter |
| 22:51 | <roc> | why? How much text do you have? |
| 22:51 | <onitunes> | look guys, if this is not critical and patches will be rejected, we should move on |
| 22:51 | <othermaciej> | have you tried it, or is that a guess? |
| 22:51 | <onitunes> | I can already git it to work |
| 22:51 | <onitunes> | with the approach I have now |
| 22:51 | <annevk3> | I've heard from a similar project that also split up the text and only parsed the displayed bit |
| 22:52 | <onitunes> | othermaciej: I've tried it |
| 22:52 | <annevk3> | because of slowness |
| 22:52 | <othermaciej> | I would like to solve your use case, but drawing manually on a <canvas> is a really poor approach to text editing |
| 22:52 | <onitunes> | text *rendering* |
| 22:52 | <roc> | onitunes: we genuinely want to understand your needs and figure out how to meet them |
| 22:52 | <onitunes> | you guys keep forgetting that |
| 22:52 | <onitunes> | I'm not asking about editing |
| 22:52 | <onitunes> | I don't use any of your editing stuff now |
| 22:52 | <Hixie> | if you're not doing editing, then why is performance slow? |
| 22:52 | <onitunes> | and I won't be starting anytime soon |
| 22:52 | <Hixie> | it's just a one-off thing if you're not editing |
| 22:52 | <othermaciej> | onitunes: if you post an example of it done that way, I would be glad to profile |
| 22:52 | <onitunes> | ah, I *am* doing editing |
| 22:53 | <Hixie> | if you're doing editing, then you should be doing contentEditable. |
| 22:53 | <onitunes> | othermaciej: okay, will add todo list |
| 22:53 | <othermaciej> | onitunes: and figure out whether there are things that can be optimized, or if there is some way to come up with a design that lets you dynamically provide data for only the visible area, or something |
| 22:53 | <Hixie> | onitunes: we want to solve your whole use case, not just the part you want us to solve, because we think we can solve the problem better than you :-) |
| 22:53 | <othermaciej> | I would not expect the DOM approach to be that bad |
| 22:54 | <onitunes> | Hixie: *that* much I get |
| 22:54 | <othermaciej> | WebKit's own Web Inspector uses HTML markup for syntax highlighting |
| 22:54 | <onitunes> | well, this is easily confirmed with tests |
| 22:55 | <onitunes> | and you can see how I "fix" the problem |
| 22:55 | <othermaciej> | indeed |
| 22:55 | <onitunes> | thanks everyone, it looks like the ball is in my court moving forward |
| 22:55 | <othermaciej> | tests = good |
| 22:56 | <othermaciej> | I guess in general, when the normal browser way of doing something is too slow or otherwise unsuitable for some use case, we are generally more interested in enhancing the built-in functinality, than in providing an alternate super low-level way to build it yourself |
| 22:57 | <othermaciej> | not always, but I think that is usually the bias of browser vendors and standards folks |
| 22:58 | <onitunes> | I agree with that approach in general, until programmers start implementing low-level APIs _on top of_ the high-level APIs that are provided, which is what I've done |
| 22:59 | <othermaciej> | I would look at such incidents as an opportunity to find out why we did not serve that programmer's use case well with existing API |
| 22:59 | <othermaciej> | but I would probably not assume "add low-level API" is the solution |
| 23:00 | <othermaciej> | I think that drawing one's own text to a bitmap, in particular, is a very bad thing |
| 23:00 | <othermaciej> | so I'd like to make sure people don't feel they need to go to such extreme measures |
| 23:00 | <onitunes> | othermaciej: that's an *amesome* quotable |
| 23:00 | <onitunes> | awesome |
| 23:01 | <onitunes> | "I think that drawing one's own text to a bitmap, in particular, is a very bad thing" |
| 23:01 | <onitunes> | :) |
| 23:01 | othermaciej | fails to see why his remark was remarkable, but ok... |
| 23:03 | <onitunes> | so, othermaciej, how do you feel about sIFR? |
| 23:03 | <onitunes> | just kidding... |
| 23:04 | <othermaciej> | if I need to explain, then I'll just say that if you draw your own text, you don't get support for the browser features of screen reader integration, copy/paste, find in page, correct bidi layout of text across, line breaks, and history search through text indexing; or the general Web feature of documents being searchable through search engines (granted, some of these don't necessarily apply in the text editing context), and probably m |
| 23:04 | <othermaciej> | even if the right low-level APIs existed to do all these things "by hand", it would be very hard to get them right |
| 23:04 | <roc> | or IMEs |
| 23:04 | <othermaciej> | so my inclination is to find out why the current rich text editing support of Web browsers is unsuitable, and try to make it suitable |
| 23:05 | <Hixie> | not to mention selection and drag and drop |
| 23:05 | <othermaciej> | rather than assuming people will write their own text editing/display logic by hand |
| 23:05 | <onitunes> | I can already do that stuff with the low-level API I've build on top of your high-level APIs |
| 23:05 | <onitunes> | including selection and drag and drop |
| 23:05 | <Hixie> | that i'd like to see :-) |
| 23:05 | <onitunes> | I'm a programmer, just like you guys |
| 23:05 | <onitunes> | nothings impossible |
| 23:05 | <onitunes> | just potentially slowv |
| 23:05 | <othermaciej> | since few would even be willing to try the latter, and most who do will fail to get it right |
| 23:06 | <othermaciej> | onitunes: got a demo page up? |
| 23:06 | <roc> | onitunes: you won't get the right per-platform selection behaviour, that's for sure, since you have no way to know what the platform selection behaviour actually is |
| 23:06 | <onitunes> | it's an IDE |
| 23:06 | <onitunes> | the selection behavior is IDE-specific |
| 23:06 | <onitunes> | and language specific, for that matter |
| 23:06 | <roc> | what color should the selection be? |
| 23:07 | <onitunes> | it's an IDE, user configure that stuff |
| 23:07 | <Hixie> | should the selection extend to the edge of the window or not? |
| 23:07 | <Hixie> | should right-clicking on the selection should a "Look up in Dictionary" item, and does it work? |
| 23:07 | <onitunes> | edge of the text areaL |
| 23:07 | <onitunes> | ? |
| 23:07 | <onitunes> | yes, I draw the selection with a <canvas> overlay |
| 23:07 | <Hixie> | (i'd love to see your bidi implementation, too) |
| 23:07 | <roc> | what should the default color be, for the 99% of users who won't configure the color? |
| 23:07 | <onitunes> | I use the browsers |
| 23:07 | <othermaciej> | we do not want to encourage Web developers in general to ignore platform text editing conventions, even if you think it is the right choice for you |
| 23:08 | <onitunes> | othermaciej: it's an application |
| 23:08 | Hixie | would love to see a demo of this |
| 23:08 | <onitunes> | it's coming |
| 23:08 | <onitunes> | it's an IDE for SproutCore |
| 23:08 | <onitunes> | none of this is rocket science |
| 23:08 | <onitunes> | and I'm almost certain the feedback I'll get is "your cheating" |
| 23:08 | <onitunes> | you're |
| 23:08 | <onitunes> | because I am |
| 23:08 | <onitunes> | I have full parsers for handling the text |
| 23:09 | <onitunes> | syntaxt highlighting is trival |
| 23:09 | <onitunes> | selection handling is done against the AST, again, trivial |
| 23:09 | <Hixie> | i expect our feedback will be "this doesn't actually work like it should", not "you're cheating" :-) |
| 23:09 | <onitunes> | Hixie: haha, could be |
| 23:09 | <Hixie> | but i'd love to be proved wrong :-) |
| 23:09 | <othermaciej> | I don't really know what "cheating" would be, I am more curious whether the features I listed do in fact work correctly |
| 23:09 | <onitunes> | you guys are tough to convince |
| 23:09 | <othermaciej> | I would think getting Safari's "Find in Page" to work right with such an editing scheme is probably impossible |
| 23:10 | <othermaciej> | but the proof is in the pudding |
| 23:10 | <onitunes> | othermaciej: of course |
| 23:10 | <onitunes> | I don't support that, but I do have a solid find dialog |
| 23:10 | <Hixie> | well then |
| 23:10 | <onitunes> | it's not a web page, it's a web app |
| 23:10 | <Hixie> | you don't support find in page :-) |
| 23:10 | <onitunes> | of course |
| 23:10 | <onitunes> | not |
| 23:10 | <onitunes> | but I do support "find" |
| 23:10 | <othermaciej> | then clearly you don't support all the features I listed |
| 23:11 | <onitunes> | and it's much more comprehensive than Safari's "find in page" feature |
| 23:11 | <onitunes> | e.g. Find and Replace :) |
| 23:11 | <onitunes> | regex find |
| 23:11 | <onitunes> | (and since the text is backed by git, find in history) |
| 23:12 | <onitunes> | well, next month will be fun |
| 23:12 | <onitunes> | the IDE will be released as an alpha in the next few weeks |
| 23:14 | <othermaciej> | it sounds like you are sufficiently invested in your idea that you are perhaps past caring whether normal browser text editing could be made to work well enough for your use case |
| 23:14 | <onitunes> | othermaciej: I bet I could support Find in Page too |
| 23:14 | <onitunes> | othermaciej: right, I'm not interested at all in browser text editing |
| 23:14 | <onitunes> | I think it's impossible for you guys to implement text editing in a way that makes sense for an IDE |
| 23:14 | <onitunes> | and it's not your mandate, anyway |
| 23:15 | <othermaciej> | I would like the browser's native text editing support to be good enough for a word processor, an IDE, a mail client, or a desktop publishing type app |
| 23:16 | <othermaciej> | I think many people involved with browser development would agree |
| 23:16 | <othermaciej> | I'm not sure why you conclude that it's impossible, because people do in fact build IDEs on top of other general-purpose text editing APIs, so all I conclude is that we are missing some essential features of those APIs |
| 23:17 | <onitunes> | attribute strings, perhaps? |
| 23:17 | <othermaciej> | (or some approach that makes things fast even when style changes are dense, or something like that) |
| 23:17 | <onitunes> | hehe |
| 23:17 | <onitunes> | Core Text and you're done |
| 23:17 | <onitunes> | let us JavaScript guys do the heavy lifting |
| 23:18 | <Hixie> | why not just provide a low-level bitmap object and let you do the font rasterising too? |
| 23:18 | <Hixie> | surely that would be even more low level |
| 23:18 | <onitunes> | if you did a <text> node, where the raw source text was in the node, but the drawing was done like <canvas>, that would work |
| 23:18 | <onitunes> | then you could search for the text, etc. |
| 23:18 | <onitunes> | but still render it programmatically |
| 23:19 | <Hixie> | like i said, we have <text> already in SVG, and in HTML it's spelt <span>. Both are stylable with CSS. |
| 23:19 | <onitunes> | Hixie: I may go there |
| 23:19 | <Hixie> | onitunes: why should we provide a high-level API like CoreText if you're going to ignore it anyway? |
| 23:19 | <onitunes> | I'm going to build on it |
| 23:19 | <othermaciej> | onitunes: since you are convinced that you already know the right answer, it is hard to have a productive discussion |
| 23:20 | <othermaciej> | most people do not assume that the right answer to an insufficiently powerful text editing API is to providing an API to do your own text measuring and drawing |
| 23:20 | <Hixie> | onitunes: why do you want to build on a high-level API like CoreText instead of a low-level API like pixel-level manipulation? |
| 23:21 | <onitunes> | Hixie: I wish JavaScript could manipulate bytes efficiently |
| 23:21 | <onitunes> | oh well |
| 23:21 | <Hixie> | that we'll be adding |
| 23:21 | <onitunes> | I'll do whatever I have to do to make my application work properly |
| 23:21 | <roc> | othermaciej: I already pointed out that Daniel Glazman is building an IDE based on browser text editing, but that didn't seem to register |
| 23:22 | <onitunes> | if it gets down to rendering text on the server and drawing bitmaps with canvas, well, I would be willing to go there |
| 23:22 | <onitunes> | roc: I looked at it |
| 23:22 | <onitunes> | it's XUL based |
| 23:22 | <onitunes> | but may be ported |
| 23:22 | <roc> | XUL doesn't offer anything particularly special here, trust me |
| 23:22 | <onitunes> | anyway, that's not really my problem space, though it may look similar |
| 23:23 | <onitunes> | still, I hadn't seen that link, thanks |
| 23:23 | <roc> | you can't even render styled text spans in XUL without dropping into HTML |
| 23:23 | <othermaciej> | onitunes: I think you are proud that you did things in such a hardcore low-level way, and I am tentatively (not having seen the actual demo) impressed |
| 23:23 | <roc> | or the equivalent plain-vanilla XML |
| 23:24 | <othermaciej> | onitunes: but I still don't think that is a good design approach in general for text editing in the Web technology stack |
| 23:24 | <onitunes> | othermaciej: the big thing is I don't like bugs |
| 23:24 | <Hixie> | onitunes: based on what you've said, it sounds exactly like your problem space, though certainly it's not the way you solved the problem space |
| 23:24 | <onitunes> | I keep dropping down layers until I hit something solid |
| 23:24 | Hixie | loves bugs, obviously :-P |
| 23:24 | <onitunes> | that's true on every platform I work on |
| 23:24 | <othermaciej> | onitunes: oh, well I just love bugs, I think they are awesome, so we'll just have to agree to disagree! |
| 23:24 | <Hixie> | i think we should have more bugs! |
| 23:25 | <wilhelm> | You can have some of mine. |
| 23:25 | <othermaciej> | in fact, lemme go check in to the WebKit tree so I can add more bugs |
| 23:25 | <onitunes> | okay, leaky abstractions |
| 23:25 | <onitunes> | contenteditable is a leaky abstraction |
| 23:25 | <onitunes> | (ignoring for a second the performance problems with updating large DOM trees) |
| 23:25 | <onitunes> | it's meant for editing "rich text" |
| 23:26 | <onitunes> | so when you want to edit plain text, you get pain |
| 23:26 | <Hixie> | how can contentEditable be a leaky abstraction? It has multiple different implementations :-) |
| 23:26 | <onitunes> | and the pain is different on each browser |
| 23:26 | <onitunes> | Hixie: see previous line |
| 23:26 | <onitunes> | whereas <span> + CSS class is basically solid everywhere |
| 23:27 | <Hixie> | oh well like i said, if you want to edit plain text, we should do that by offering an API on <textarea> for formatting the text on the fly |
| 23:27 | <onitunes> | Hixie: yeah, that'd be cool |
| 23:27 | <roc> | if you've got specific contenteditable bugs that you want fixed, that is also very useful information |
| 23:27 | <onitunes> | "if you did a <text> node, where the raw source text was in the node, but the drawing was done like <canvas>, that would work" |
| 23:27 | <onitunes> | switch <text> to <textarea> and we agree, essentially, Hixie |
| 23:27 | <Hixie> | oh i don't in any way think we should do anything like <canvas> |
| 23:28 | <Hixie> | it would be UA-pull, like <datagrid> |
| 23:28 | <othermaciej> | I would be inclined to say the browser layout engine still draws the text, but perhaps with dynamic styles |
| 23:28 | <Hixie> | not author-push like <canvas> |
| 23:28 | <Hixie> | anyway |
| 23:28 | <othermaciej> | (that's assuming this can be shown to be meaningfully more efficient than adding <span>s) |
| 23:28 | <Hixie> | that's not something i plan to design today |
| 23:28 | <onitunes> | othermaciej: I'll do a write-up of the DOM approach on the RedBull wiki |
| 23:29 | <onitunes> | it's really simple (probably why its also fast) |
| 23:29 | <Hixie> | yeah just recreating the DOM nodes on the fly seems like it would probably work about as well |
| 23:29 | <Hixie> | you could do some pretty good optimisations too |
| 23:30 | <Hixie> | keeping track of state so that if you hit a point where you're back in the same state as before you just stop restyling |
| 23:31 | <onitunes> | the way I do it, given a character, I can tell you the style (== CSS class) to apply |
| 23:31 | <onitunes> | it's pretty hard to screw that up :) |
| 23:31 | <onitunes> | innerText is also pretty fast on FF |
| 23:31 | <othermaciej> | onitunes: so you scan back or forward from the character to figure out the style? |
| 23:31 | <onitunes> | othermaciej: I have a full parse tree |
| 23:32 | <onitunes> | given a character, I can identify the AST ned |
| 23:32 | <othermaciej> | onitunes: I see |
| 23:32 | <onitunes> | node |
| 23:32 | <othermaciej> | at the JS level or in native code? |
| 23:32 | <onitunes> | native |
| 23:32 | <onitunes> | I'd like to move it to CSS |
| 23:32 | <onitunes> | but it comes from the server now |
| 23:32 | <onitunes> | CSS? |
| 23:32 | <onitunes> | I meant JavaScript |
| 23:32 | <othermaciej> | what code is responsible for updating the AST in response to edits? |
| 23:32 | <onitunes> | we talked about this over on #jsc a week or so ago |
| 23:33 | <onitunes> | othermaciej: the server |
| 23:33 | <onitunes> | I forward key presses and mouse movement to the server |
| 23:33 | <othermaciej> | does it do it in some incremental way or just full reparse? |
| 23:33 | <onitunes> | incremental |
| 23:34 | <onitunes> | though the parser is very fast |
| 23:34 | <onitunes> | it's not a bottleneck right now (it's C++) |
| 23:35 | <othermaciej> | it would be cool if even that part could practically be done with JS |
| 23:35 | <onitunes> | totally agree |
| 23:35 | <onitunes> | I want to move that to JavaScript |
| 23:35 | <onitunes> | but I'm using libraries from other projects right now, so it'd be a lot of work to do that |
| 23:36 | <onitunes> | JavaScript also doesn't have mutable strings :( |
| 23:37 | <othermaciej> | I would not expect parsing to an AST to need mutable strings |
| 23:38 | <onitunes> | right, but the editing is all server-side now too |
| 23:38 | <onitunes> | I'm not sure how to do that efficiently on the client yet |
| 23:38 | <onitunes> | that's what I mean by cheating |
| 23:38 | <onitunes> | I have a really smart server and a really dumb browser client |
| 23:39 | <othermaciej> | props for bucking the trend |
| 23:40 | <othermaciej> | I do not think mutable strings are required for editing either; there are some specialized buffer structures for efficiently inserting into or deleting from the middle of a text buffer (like Emacs uses) but I don't think a general-pupose mutable string would help much |
| 23:41 | <onitunes> | I could use arrays, but there's not AFAICT an easy way to go from an integer to a character in a string |
| 23:41 | <onitunes> | that would be helpful |
| 23:41 | <onitunes> | :-) |
| 23:41 | <onitunes> | I've used a switch statement in the past, but it's not fast |
| 23:41 | <onitunes> | or at least, it wasn't |
| 23:41 | <onitunes> | I think you guys have some improvements there now |
| 23:42 | <gavin> | fromCharCode? |
| 23:42 | <onitunes> | gavin: you're my hero |
| 23:43 | <gavin> | I'm not sure that using arrays for strings is going to win you anything |
| 23:43 | <jcranmer> | charCodeAt and fromCharCode |
| 23:43 | <onitunes> | I need a better JavaScript reference :/ |
| 23:43 | <jcranmer> | I have some JS code that does btoa and atob |
| 23:44 | <gavin> | why would you do btoa/atob in js? |
| 23:44 | <othermaciej> | modern JS implementations are pretty efficient at handling cases where you split and recombine strings |
| 23:44 | <othermaciej> | ad particularly incremental append |
| 23:44 | <gavin> | does IE not have it as a global on the Window? |
| 23:44 | <jcranmer> | gavin: because a) I don't have a window object lying around and b) I'm doing protocol I/O |
| 23:45 | <gavin> | jcranmer: what do you have, then? |
| 23:45 | <jcranmer> | gavin: whatever xpcshell has |
| 23:45 | <gavin> | jcranmer: atob/btoa were recently added for xpcom components, adding them to xpcshell shouldn't be very hard if it's not already done |
| 23:46 | <gavin> | I'd be interested in seeing your version though |
| 23:46 | <gavin> | I've written a couple that predate the availability of it in components |
| 23:46 | <jcranmer> | http://hg.mozilla.org/users/Pidgeot18_gmail.com/trunk_mq/file/c05017b8babc/imapfakeserver#l1927 |
| 23:49 | <jcranmer> | definitely writtin for JS, though |
| 23:54 | <gavin> | ah, mine was http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/search/nsSearchService.js&rev=1.92#269 |
| 23:54 | <gavin> | took a byte array though |
| 23:54 | <gavin> | simon improved it a bit in https://bugzilla.mozilla.org/show_bug.cgi?id=363318#c17 |