| 00:17 | <JonathanNeal> | Do some of you folks work on the whatwg project? |
| 00:17 | <Hixie> | this _is_ the whatwg project |
| 00:20 | <JonathanNeal> | Nice. |
| 00:23 | <JonathanNeal> | Now we're moving to the second portion of the HTML5 adoption, which is applying it to our latest out-of-the-box theme. I have an example @ http://madison.thewikies.com/html5/liferay/ |
| 00:24 | <JonathanNeal> | I'm still working on getting the code for our div based columns. So I know I'm losing everything inside the tables. |
| 00:54 | <Hixie> | o_O |
| 00:54 | <Hixie> | now leif is suggesting ARIA should be used by non-ATs |
| 00:54 | <Hixie> | going directly contrary to the point of ARIA... |
| 01:05 | <Hixie> | well this is dumb |
| 01:05 | <Hixie> | the way i designed the database API, you can't know whether you need to create the tables or not |
| 01:06 | <Hixie> | <-- dumb |
| 01:49 | <jlebar> | Hixie, does [6.11.9 History Traversal] occur on all page loads, even if I type straight into the URL bar? |
| 01:49 | <Hixie> | yes |
| 01:49 | <Hixie> | it is invoked as part of the navigation algorithm |
| 01:49 | <jlebar> | So is popstate fired on all loads? |
| 01:49 | <Hixie> | no |
| 01:49 | <Hixie> | only if there is state to pop |
| 01:50 | <jlebar> | Only if the state to pop is non-null? |
| 01:50 | <jlebar> | I could set the document pending object to null as part of the algorithm. |
| 01:53 | <Hixie> | hold on |
| 01:55 | <Hixie> | jlebar: ok, here now. looking... |
| 01:56 | <Hixie> | jlebar: popstate only fires when an entry in the session history is activated |
| 01:56 | <Hixie> | jlebar: which only occurs if the specified entry is a state object or the first entry for a Document |
| 01:57 | <Hixie> | jlebar: but yes, it fires at least once per Document load |
| 01:57 | <Hixie> | s/but/so/ |
| 01:57 | <Hixie> | my statement earlier was incorrect |
| 01:58 | <Hixie> | jlebar: sorry about that! |
| 02:01 | <jlebar> | Hixie, sorry, was afk for a sec. I'm not totally clear on this: If we load index.html and then go to index.html#foo, do we get one or two popstates? |
| 02:02 | <jlebar> | Once for the initial document load... |
| 02:02 | <Hixie> | one |
| 02:02 | <jlebar> | I see. |
| 02:02 | <Hixie> | you get one for the page load |
| 02:02 | <jlebar> | And if we go back to index.html, we also don't get a popstate, because index.html doesn't have an associated state object. |
| 02:02 | <Hixie> | right |
| 02:03 | <Hixie> | er |
| 02:03 | <Hixie> | well actually... |
| 02:03 | Hixie | looks closer |
| 02:03 | <jlebar> | :) |
| 02:03 | <Hixie> | actually yes, you do |
| 02:03 | <Hixie> | you always get a popstate when traversing to the first entry in the history for a Document |
| 02:03 | jlebar | is relieved. |
| 02:03 | <jlebar> | Oh...interesting. |
| 02:03 | <Hixie> | not sure that's entirely sane |
| 02:03 | <Hixie> | but it's what it says |
| 02:03 | <jlebar> | Me either. |
| 02:04 | <jlebar> | I've been dispatching popstate whenever we dispatch onload, and also when you go back/forwards to any history entry. |
| 02:05 | <jlebar> | That might be easier for developers to deal with, since it's somewhat consistent. |
| 02:05 | <Hixie> | the original intent was to only dispatch it when hitting an entry that has been pushState()d |
| 02:05 | <Hixie> | i am not sure why we dispatch for the initial page load |
| 02:05 | <jlebar> | I think because you want to know when you go back to it? |
| 02:05 | <Hixie> | i guess, yeah |
| 02:06 | <Hixie> | yeah, that makes sense |
| 02:06 | <jlebar> | So it treats the first history entry for a document as one which was pushState()ed to. |
| 02:06 | <Hixie> | right |
| 02:06 | <Hixie> | that makes sense i guess |
| 02:06 | <jlebar> | maybe? :) |
| 02:06 | <Hixie> | :-) |
| 02:06 | <Hixie> | so the only entries for which you don't fire a popstate per spec are those that were added due to the hash changing |
| 02:06 | <Hixie> | (they get a hashchange) |
| 02:07 | <jlebar> | I see. That might be a little confusing, because clearstate does clear those. |
| 02:07 | <Hixie> | yeah, that was a recent change |
| 02:08 | <Hixie> | iirc |
| 02:08 | <Hixie> | or at least, that wasn't my original intent |
| 02:08 | <Hixie> | thing is, if we do fire popstate for everything |
| 02:08 | <Hixie> | then authors are going to have to distinguish the state=null-because-first case from the state=null-because-hashchange-will-fire-next case |
| 02:09 | <Hixie> | and that's probably harder than just dealing with those two cases |
| 02:10 | <jlebar> | Hm... I'm not yet convinced that matters. Wouldn't they listen to popstate alone in that case? |
| 02:11 | <jlebar> | * rephrased: If they just ignore hashchanges, do they care about differentiating between them? |
| 02:11 | <Hixie> | if they don't distinguish them, then each time the user changes the hash manually, the page is going to reset to the initial state |
| 02:11 | <jlebar> | Hmm |
| 02:13 | jlebar | wonders how this would change if we had a setState() function. Then you *could* associate state with the initial entry. |
| 02:14 | <Hixie> | true |
| 02:14 | <Hixie> | but it's easy enough to remember the state for the initial state |
| 02:15 | <Hixie> | i mean, what they _should_ do is if state is null, or if hashchange is called, just base the state on the url |
| 02:15 | <Hixie> | i guess we could call popstate always |
| 02:15 | <Hixie> | do any other UAs implement this yet? |
| 02:15 | <jlebar> | That's how I've been imagining it working. That way you can bookmark the page and it'll do the right thing. |
| 02:15 | <jlebar> | I'm not aware of any other UAs working on this. |
| 02:15 | <Hixie> | try e-mailing the list and seeing what others think of it |
| 02:16 | <jlebar> | Will do. |
| 02:16 | <Hixie> | if it's not too late for shipped implementations, i can change it to just always fire popstate |
| 02:16 | <Hixie> | my contribution to the web: events firing all the damn time. :-/ |
| 02:16 | <jlebar> | Okay. I'll try and send out an e-mail soon. I have a few other things in there, but they don't require the Author to parse the spec for me. :) |
| 02:16 | <Hixie> | i guess nothing i've done with events is as bad as mutation events, still |
| 02:16 | <Hixie> | jlebar: k :-) |
| 02:17 | <jlebar> | Thanks, Hixie. |
| 02:17 | <Hixie> | np |
| 02:17 | Hixie | wonders why adding features to the web platform feels like a continuous exercise in damage mitigation |
| 02:17 | <Hixie> | it's like trying to build a sandcastle under a waterfall |
| 02:18 | <jlebar> | lol. And you have four large, powerful groups of people all telling you that they don't like the shape of your crenelations. |
| 02:18 | <Hixie> | fan more than four |
| 02:19 | <Hixie> | far, even |
| 02:19 | <Hixie> | there's the IETF people, the accessibility people, microsoft, google, apple, mozilla, opera, the TAG, the RDFa people... |
| 02:19 | <jlebar> | Yeah. I'm only just beginning to get into this, but...I don't envy that. |
| 02:20 | <Hixie> | eh, the sad thing is i enjoy it |
| 02:20 | <Hixie> | i'm a sucker i guess :-P |
| 02:20 | <jlebar> | :) I need to go catch my train now. Thanks again! |
| 02:20 | <Hixie> | later! |
| 05:02 | <Hixie> | shepazu: xhr was part of html5 |
| 05:02 | <Hixie> | it was the first spec to be spun off |
| 06:13 | <JonathanNeal> | Hello all. |
| 06:18 | <Hixie> | anyone know how focus and blur events work on Window objects? |
| 06:23 | <othermaciej> | Hixie: I think they fire based on the window gaining or losing focus |
| 06:23 | <othermaciej> | more detail than that, I don't know |
| 06:24 | <Hixie> | i guess i'll look into it on wednesday |
| 06:24 | <Hixie> | bed now |
| 06:24 | <Hixie> | nn |
| 06:37 | <JonathanNeal> | Night, Hixie. |
| 06:39 | <JonathanNeal> | focus is when a particular element is active, like when a link is selected and has that little dotted outline in firefox, or when your mouse is pressed inside an input element and the text cursor is flashing, when you "enter" that element, that is focus. |
| 06:39 | <JonathanNeal> | Blur is the opposite and occurs only when you leave a particular element. |
| 06:40 | <JonathanNeal> | oh geez, you asked about window objects, not elements. |
| 06:40 | <JonathanNeal> | If you're talking about the window that shows you the body of the page, then it works the same as the elements. |
| 06:41 | <JonathanNeal> | when the window is active and when you're on the tab of that particular page, it's active. |
| 06:42 | <JonathanNeal> | you have to actively leave the tab by switching to another one or minimizing the window to trigger blur. |
| 07:39 | <shepazu> | Hixie: XHR came to W3C long before HTML5 did... with regards to the Rec track, it's not a "spin-off" in that sense |
| 07:41 | <annevk2> | not that long |
| 07:41 | <annevk2> | less than a year |
| 07:42 | <annevk2> | and it did came out of what became known as HTML5 later |
| 07:49 | <annevk2> | it's even part of the acknowledgments |
| 07:51 | hsivonen | thinks the maturity level req for normative references is entirely unhelpful |
| 07:53 | <annevk2> | XMLHttpRequest is not moving that fast at the moment |
| 07:53 | <annevk2> | mostly awaiting more impl feedback |
| 07:57 | <othermaciej> | shepazu: it was spun off before WHATWG Web Apps 1.0 was officially adopted as W3C HTML5 |
| 07:58 | <othermaciej> | hsivonen: it somewhat makes sense to me that, if you normatively depend on an unstable spec, it's dubious to declare yourself frozen |
| 07:58 | <othermaciej> | hsivonen: but since Web technology has turned out to be a web of specs and not a hierarchy, it does seem like it could impede progress |
| 08:01 | <hsivonen> | othermaciej: implementations aren't going to stabilize at a point where they are only implementing RECs |
| 08:02 | <othermaciej> | hsivonen: that tends to undermine the idea of RECs at all |
| 08:02 | <hsivonen> | othermaciej: instead, any particular piece of the platform may advance ahead of components that rely on the service the piece provides |
| 08:02 | <othermaciej> | I am not sure what the right process is for Web standards |
| 08:02 | <hsivonen> | othermaciej: I'm not a believer in RECs, either. |
| 08:02 | <othermaciej> | implementations move too fast |
| 08:03 | <othermaciej> | for the traditional standards process |
| 08:03 | <othermaciej> | but never stabilizing anything also seems like a bad idea |
| 08:04 | <hsivonen> | it makes sense to stabilize stuff, but making spec division as granular as actual stability would be prohibitively bureaucratic |
| 08:04 | <hsivonen> | we'd have on W3C doc per DOM method |
| 08:04 | <hsivonen> | s/on/one/ |
| 08:05 | <hsivonen> | even the WHATWG section-level stability isn't quite granular enough to annotate real implementation stability |
| 08:06 | <hsivonen> | I rather like the analogy Hixie made with U.S. Code |
| 08:06 | <othermaciej> | probably still more practical than doing it per-method |
| 08:08 | <annevk2> | shepazu, please... |
| 08:09 | <annevk2> | (re latest email) |
| 08:16 | <shepazu> | annevk2: what? you raised a totally pedantic point that wasn't even correct, nor was it pertinent to the subject at hand... you expected a serious reply? |
| 08:18 | <annevk2> | dream on |
| 08:18 | <hsivonen> | shepazu: what was annevk2's pedantic point? |
| 08:20 | <shepazu> | the same as hixie's, naturally... to which I'd already replied in this channel |
| 08:27 | <annevk2> | hmm |
| 08:27 | <annevk2> | the WHATWG twitter account is no longer updated? |
| 08:28 | <annevk2> | probably a problem with twitter I suppose :/ |
| 08:43 | <othermaciej> | shepazu: the original contents of the W3C XHR spec were once in "Web Apps 1.0", which at the time was known unofficially as HTML5 and now is known officially as HTML5 |
| 08:44 | <othermaciej> | shepazu: I'm not sure what your goal is in casting doubt on that record |
| 09:16 | <shepazu> | othermaciej: "casting doubt on that record"? I laid it out explicitly... you might as well ask what anne's point was in claiming XHR originated with the HTML5 spec... it's totally irrelevant to the explanation I was making for Shelley about what the relationship of specs on the Rec-track are |
| 09:17 | <annevk5> | I was just making a small nit about your statement being the editor of XMLHttpRequest and all |
| 09:17 | <shepazu> | why is it always a political debate when someone gets off the party line? |
| 09:17 | <othermaciej> | shepazu: the part of your email he quoted said "XmlHttpRequest (XHR) spec, which was never part of HTML5" |
| 09:17 | <othermaciej> | I think he just gave a simple factual correction, from his perspective |
| 09:17 | <othermaciej> | I don't believe anyone but you is making it political |
| 09:17 | <shepazu> | pft. |
| 09:18 | <othermaciej> | it was a side point which I don't think invalidates the rest of your comments |
| 09:19 | <aho> | void save(); // push state on state stack |
| 09:19 | <aho> | void restore(); // pop state stack and restore state |
| 09:19 | <aho> | why aren't these called push and pop? |
| 09:19 | <aho> | save and restore makes it sound like there can be only one state |
| 09:19 | <shepazu> | wtf??? http://www.fujinonbinos.com/ |
| 09:20 | <shepazu> | (view source) |
| 09:21 | <hsivonen> | shepazu: awesomeness |
| 09:21 | <shepazu> | code as art? |
| 09:22 | <othermaciej> | my eyes hurt |
| 09:22 | <shepazu> | the Poseidon Series, appropriately, goes very deep |
| 09:23 | <foolip> | jgraham, Philip`: did either of you happen to implement the DOM APIs for microdata for your demos? I'm wanting to do a microdata experiment but am too lazy to implement the API myself |
| 09:23 | <annevk5> | sicking, I think another important reason for alt= has been search engines |
| 09:24 | <shepazu> | <META NAME="generator" CONTENT="Web Studio, Version 4.0 for Windows"> |
| 09:37 | <jgraham> | foolip: No, mine is python based |
| 09:38 | <jgraham> | so it doesn't really have a concept of DOM |
| 09:38 | <foolip> | too bad |
| 09:38 | <jgraham> | Philip`'s was js based though. I don't know if he tried implementing the DOM APIs |
| 09:39 | <foolip> | I'll have a look then |
| 09:40 | <othermaciej> | annevk2: do search engines read alt? |
| 09:40 | <othermaciej> | annevk2: I wonder why it has not become a search engine spam vector (or maybe it has) |
| 09:46 | <annevk5> | othermaciej, I think it's in every SEO text book (not that I ever read one) |
| 09:47 | <hsivonen> | on the codec topic: did VLC regress or remove Dirac support? |
| 10:41 | <annevk5> | so Firefox does support ISO88599 unlike IE but like Chromium and Opera |
| 10:41 | <annevk5> | but it does not support ISO-8859_9 unlike IE, Chromium and Opera |
| 10:50 | <aho> | how about ISO-8859-9? :> |
| 10:51 | <annevk5> | including the question mark? </smart-ass> |
| 10:51 | <aho> | wouldnt be a question then, would it? :P |
| 10:52 | <annevk5> | you win :) |
| 12:50 | <Dashiva> | What are the non-aria uses of role now that xhtml2 is going away? |
| 12:50 | <hsivonen> | Dashiva: none |
| 12:52 | gsnedders | guesses Hixie is sleeping |
| 12:52 | <Dashiva> | Then what's up with the role vs aria-role thread? |
| 12:54 | <annevk5> | I don't think everyone is in agreement that role="" is just for WAI-ARIA |
| 12:54 | <hsivonen> | Dashiva: role is an inconsistent name when everything else in ARIA has the aria-* prefix |
| 12:54 | <hsivonen> | Dashiva: it sucks, but it's too late. not too serious to worry about, IMO. |
| 12:55 | <hsivonen> | annevk5: who disagrees except the XHTML2 WG? |
| 12:55 | <annevk5> | The people who brought it up I assume |
| 12:56 | <Dashiva> | But nobody knows here what other uses are being considered? |
| 12:59 | <annevk5> | I don't fully understand what they want |
| 13:06 | <Lachy> | I don't understand that thread at all. Jim stated in his e-mail about it that "ARIA roles are not the *only* use of the role attribute", and regardless of whether that's true or not, it refutes his own argument for making it aria specific |
| 13:07 | <hsivonen> | non-ARIA uses of role are handled by class :-) |
| 13:08 | <Dashiva> | <element element-role="div"> |
| 13:10 | <jgraham> | I think he wants aria-role and role so that you can have <input type=checkbox aria-role=radio role=url> |
| 16:13 | <zcorpan> | http://www.w3.org/mid/op.uyupstgqidj3kv⊙sl |
| 16:14 | <annevk2> | back to ABNF? |
| 16:15 | <annevk2> | or XML BNF or whatever it is |
| 16:15 | <zcorpan> | it's XML 1.0 EBNF |
| 16:16 | <annevk2> | so the new rule is not matching the EBNF is ignoring the entire PI? |
| 16:16 | <zcorpan> | yeah |
| 16:17 | <zcorpan> | plus duplicate pseudo-attribute and � |
| 16:19 | <annevk2> | XML infoset? :/ |
| 16:20 | <zcorpan> | the wg doesn't like having it defined in terms of the dom, because not all impl use a dom... |
| 16:20 | <zcorpan> | but they were fine with infoset |
| 16:21 | <annevk2> | hmm, it also doesn't define impl requirements anymore it seems |
| 16:21 | <annevk2> | e.g. section 5 seems more like a description for authors than implementors |
| 16:23 | <annevk2> | http://simon.html5.org/specs/xml-stylesheet5 is nicer :) |
| 16:24 | annevk2 | is somewhat positively surprised with http://www.ietf.org/mail-archive/web/http-state/current/msg00191.html |
| 16:38 | <jgraham> | http://news.bbc.co.uk/2/hi/science/nature/8206280.stm |
| 16:38 | <jgraham> | MikeSmith in particular should take note of the guy's name |
| 16:44 | <Lachy> | "Professor Robert Smith? (the question mark is part of his surname and not a typographical mistake) ..." - That guy must have had some weird parents to have given him a question mark in his name |
| 16:45 | <jgraham> | Lachy: Given that it is to distinguish him from the more famous Robert Smith I guess he got his name changed |
| 16:45 | <jgraham> | Kinda like Mike(TM)Smith but moreso |
| 16:45 | <Lachy> | I hadn't read that far through the article to see that yet |
| 16:46 | <Lachy> | So I guess he added it himself |
| 16:46 | <gsnedders> | n00b |
| 16:50 | <Dashiva> | jgraham: It's a shame the study uses such a flawed model |
| 16:51 | <Dashiva> | Pretty basic mistake, too, I wonder how they missed it |
| 16:52 | <zcorpan> | gsnedders: fixed the charref issue |
| 17:03 | <jgraham> | Dashiva: I assume the study was designed to give the publicity-happy result |
| 17:04 | <jgraham> | Although that may be unduly cynical, it is worth noting that it is by someone who thought that doing a study on disease propogation using zombies was a good idea and who appended a question mark to their name |
| 17:06 | <Dashiva> | So you believe that in a model where zombies can't re-reanimate, humans and zombies could coexist peacefully? |
| 17:08 | <annevk5> | jgraham, good enough to make BBC News |
| 17:08 | <annevk5> | apparently :) |
| 17:08 | <Dashiva> | Props to BBC for finding a guy smart enough to point out the obvious flaw in the study :) |
| 17:11 | <jgraham> | annevk5: "silly season" |
| 17:11 | <annevk5> | which reminds me, where is RB? |
| 17:13 | <zcorpan> | annevk2: don't summon him please |
| 17:15 | <jgraham> | I have to say that every time Dmitry Titov posts I have a momentary panic that it is Dmitry Turin |
| 17:18 | <annevk5> | foolip, gonna blog about http://twitter.com/foolip/status/3384463111 ? |
| 17:19 | <foolip> | annevk5: maybe after a finish an experiment with the Microdata DOM API (which I have to implement first) |
| 17:19 | <foolip> | s/a/I/ |
| 17:20 | <foolip> | (in JS that is, not in browser) |
| 17:22 | <gsnedders> | "If current node is a pre, textarea, or listing element, append a U+000A LINE FEED (LF) character." — does anything do that? |
| 17:22 | <gsnedders> | As far as I can tell nothing does that |
| 17:25 | <jgraham> | Doesn't seem worth worrying about unless it causes compat issues |
| 17:25 | <annevk5> | but things probably should because otherwise we lose a \n each time it's parsed and then serialized |
| 17:26 | <annevk5> | and then parsed again, doh |
| 17:26 | <annevk5> | foolip, k |
| 17:41 | <JonathanNeal> | Goodmorning! |
| 17:41 | <zcorpan> | hsivonen: a difference with parsing into the element itself when setting innerHTML (instead of doing what the spec says): <pre>.innerHTML = '\nx' |
| 17:42 | <Lachy> | Good evening JonathanNeal |
| 17:52 | <JonathanNeal> | Hello all. |
| 17:52 | <JonathanNeal> | I mean, goodevening Lachy. |
| 17:56 | <JonathanNeal> | Where are you based? |
| 18:01 | <miketaylr> | it's lunch time over here, so good afternoon JonathanNeal |
| 18:10 | <JonathanNeal> | Goodevening Lachy and goodafternoon miketaylr. |
| 18:12 | <Dashiva> | i18n('greeting') |
| 18:12 | <JonathanNeal> | Thanks for all of your guys help so far, I'm making good progress with http://madison.thewikies.com/html5/liferay/ and I'll be working on the core of the portal to have the default unstyled theme be an HTML5 semantic document. |
| 18:49 | <Lachy> | JonathanNeal, I'm in Norway |
| 18:50 | <JonathanNeal> | Groovy. |
| 20:34 | <othermaciej> | hi everyone |
| 20:36 | <TabAtkins> | Yo, Maciej |
| 22:26 | <JonathanNeal> | hi othermaciej, delayed. |
| 22:48 | <Philip`> | foolip: I tried starting to implement the microdata DOM stuff, before deciding it required more effort and knowledge than I wanted to bother with |
| 23:04 | Philip` | tries to work out how to change Google from its silly geolocated Spanish default into English |
| 23:04 | Philip` | fails, since he doesn't know the Spanish for "English" |
| 23:05 | <Philip`> | Aha, got it now, by going through Hebrew and Pirate |
| 23:16 | <annevk5> | Dashiva, took a few minutes to hack this together before going to bed: http://dump.testsuite.org/2009/encoding-matching/runtests.htm |
| 23:18 | annevk5 | wonders if contentDocument works in IE8 |
| 23:21 | <JonathanNeal> | FAIL |
| 23:21 | <JonathanNeal> | annevk5 doesn't like me. |
| 23:21 | <Dashiva> | annevk5: The iframe is so tiny! |
| 23:22 | <TabAtkins> | Philip: Hahaha. It's "ingles", by the way (there's an accent in there, but irrelevant here). |
| 23:23 | <annevk5> | Dashiva, the frame is not really relevant |
| 23:24 | jgraham | wishes you could tell what you failed/passed |
| 23:24 | <Dashiva> | annevk5: You might have to use contentWindow.document |
| 23:24 | <annevk5> | yeah, I thought of adding titles |
| 23:25 | <Philip`> | TabAtkins: Ah, right - I had no chance if it didn't begin with "E" |
| 23:26 | <annevk5> | now it reports the title and uses contentWindow |
| 23:26 | <Dashiva> | Hmm, or no |
| 23:26 | <TabAtkins> | Eh, as long as you can read the alphabet, most languages translate English relatively understandably. It *does* mean you may have to read through a whole list of unknown foreign words, though. |
| 23:26 | <Dashiva> | That wasn't the problem, it's the onload that doesn't fire |
| 23:27 | <annevk5> | ok, I'll change some things |
| 23:27 | <Dashiva> | Apparently it doesn't support onload, only attachEvent with load? |
| 23:30 | <Dashiva> | Or you can use the onload attribute |
| 23:31 | <annevk5> | try it now? |
| 23:33 | <annevk5> | can't believe this is taking more than 30 minutes |
| 23:34 | <Dashiva> | Yeah, it's running now |
| 23:35 | <annevk5> | cool |
| 23:35 | <Dashiva> | Could you include a \n in the output? :) |
| 23:35 | <annevk5> | you mean \r then? |
| 23:35 | <Dashiva> | Oh, right. Yeah. |
| 23:36 | <TabAtkins> | God, the /r/n debacle is one of the most nonsensical interop failures ever. |
| 23:36 | <annevk5> | done |
| 23:36 | <annevk5> | can't believe IE still hasn't fixed that |
| 23:36 | <annevk5> | well I can |
| 23:36 | <annevk5> | it just annoys me |
| 23:37 | <Dashiva> | WTf... it's still all on one line |
| 23:38 | <annevk5> | ok, i'll fix that too before I go to sleep |
| 23:38 | <annevk5> | hold on |
| 23:38 | <Dashiva> | They don't appear if I alert document.body.innerHTML either |
| 23:40 | <annevk5> | reload |
| 23:41 | <Dashiva> | works |
| 23:41 | <Dashiva> | Now it just needs color coding in the list and you're done ;P |
| 23:41 | <annevk5> | mwaha, guess what finger I'm holding up :p |
| 23:41 | <annevk5> | anyway, thanks for the help, much appreciated :) |
| 23:42 | <Dashiva> | 25-27 all fail, by the way |
| 23:42 | <annevk5> | ah interesting |
| 23:42 | <annevk5> | I wonder why the other browsers recognize those aliases |
| 23:42 | <Dashiva> | Oh, there's a bug |
| 23:42 | <Dashiva> | ... |
| 23:42 | <annevk5> | ... |
| 23:42 | <Dashiva> | No, that's just me needing sleep |
| 23:42 | <annevk5> | profit |
| 23:43 | <TabAtkins> | I get a fail on 25 and 27 on FF 3.5.2 |
| 23:43 | <annevk5> | me too |
| 23:43 | <Dashiva> | Opera fails 001... wtf |
| 23:43 | <annevk5> | TabAtkins, yeah me too, not entirely unexpected, with the last few I was just playing around |
| 23:43 | <TabAtkins> | Plenty of others, too. But just saying that "the other browsers" don't recognize those. |
| 23:43 | <TabAtkins> | Ah, kk. |
| 23:43 | <annevk5> | Dashiva, we don't alias ISO-8859-9 to Windows-1254 yet |
| 23:43 | <annevk5> | filed a bug on it today |
| 23:43 | <Dashiva> | Opera passes 25-27, though. Heh. |
| 23:44 | <annevk5> | Firefox doesn't do that either, hence it failing tests |
| 23:44 | <annevk5> | if it did that it would pass mosts |
| 23:45 | <annevk5> | anyway, nn |
| 23:45 | <Dashiva> | nn |
| 23:46 | <TabAtkins> | nn = nighty night, right? |
| 23:47 | <Dashiva> | never normalize |
| 23:47 | <TabAtkins> | Ah, makes sense. |
| 23:48 | <TabAtkins> | wtf, php. It's telling me that it's max int is 2^31, as expected, and that is uses 4-bit ints. But it's also storing and showing me the number 11billion, which should require 34 bits to store. |
| 23:49 | <mpilgrim> | annevk5: are you looking for results of those encoding tests? |
| 23:49 | <mpilgrim> | if so, which browsers? |
| 23:50 | <Dashiva> | I think he has all he needs for now |
| 23:50 | <mpilgrim> | ok |
| 23:50 | <mpilgrim> | what do they test? |
| 23:50 | <Dashiva> | charset parsing and aliasing, as far as I know |
| 23:51 | <TabAtkins> | That's what it looks like, yah. |
| 23:51 | <Dashiva> | mpilgrim: When will the first chapter of your new book be ready? :) |
| 23:51 | <gsnedders_> | TabAtkins: It implicitly converts from ints to floats as needed |
| 23:51 | <mpilgrim> | as soon as i finish the last book |
| 23:52 | Dashiva | chuckles at 4-bit ints |
| 23:52 | gsnedders_ | noticed that too :) |
| 23:54 | <TabAtkins> | Hrm. Then how is it keeping accuracy? Just checked against my lisp implementation the value of a 7-digit number in base 32 (relevant to what I'm doing), and PHP and Lisp agree. |
| 23:54 | <TabAtkins> | And I know Lisp uses bigints. |
| 23:54 | <TabAtkins> | (the max 7-digit value, that is) |
| 23:55 | <TabAtkins> | I think my PHP is secretly using 8B ints and lying to me. |
| 23:55 | TabAtkins | just got what Dashiva and gsnedders were chuckling at. |
| 23:55 | <Dashiva> | mpilgrim: You note that Opera doesn't support text in ch4, but one of the examples earlier in the chapter uses text (and thus doesn't match the text in Opera) |
| 23:55 | <mpilgrim> | yes |
| 23:55 | <mpilgrim> | the print edition will obviously use static images |
| 23:56 | <mpilgrim> | i tried to be up-front about it in each section |
| 23:56 | <mpilgrim> | if your browser has an "x", the section examples may not make sense |
| 23:56 | <mpilgrim> | might end up using static images for the online edition too, and having separate example pages |
| 23:56 | <Dashiva> | *nod* |
| 23:57 | <Dashiva> | Just thought this might be confusing since the x for text won't appear for another few scrolls |