| 00:10 | <hober> | "I'm not going to go all 'hixie' on your asses." -- shane mccarron, http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0239.html |
| 00:10 | <Dashiva> | I'm not convinced that's a good thing |
| 00:58 | <Hixie> | hober: if that isn't him "going hixie" i wonder what "going hixie" looks like |
| 00:59 | <Dashiva> | Probably involves more three-level step-by-step algorithms |
| 01:24 | <Hixie> | Dashiva: something tells me that's not what he meant |
| 01:28 | <hober> | Hixie: indeed |
| 01:34 | <MikeSmith> | perhaps he meant it involves writing good specs in general |
| 01:35 | <MikeSmith> | ones that address market needs |
| 01:35 | <MikeSmith> | and solve real problems |
| 01:53 | <nessy> | and generally getting shit done ;) |
| 02:09 | <MikeSmith> | I think the sound of "Ostanite mirni i stvorili stvari." is beautiful |
| 02:10 | <MikeSmith> | that is the best-sounding way to say it in any language I have tried so far |
| 02:16 | <nimbupani> | MikeSmith: that sounds like R2D2-speak to me :| |
| 02:17 | <MikeSmith> | heh |
| 02:18 | <MikeSmith> | "stvo" and "stva" are great ways to start words |
| 02:38 | <karlcow> | wow, that's totally innapropriate |
| 02:55 | <nessy> | google translate reckons it's serbian - cute! |
| 03:03 | <MikeSmith> | google translate usually does a pretty good job at guessing |
| 03:04 | <MikeSmith> | I wonder how much it reads in and analyzes before it makes a determination |
| 03:04 | <karlcow> | Mechanical Turk :) |
| 03:57 | <MikeSmith> | nessy: you reported your crasher? |
| 07:32 | <nattokirai> | fantasai: ping |
| 07:32 | <nattokirai> | fantasai: wondering what i should do about invalid font test... |
| 07:33 | <nattokirai> | remove it or stub it out? |
| 09:28 | <jgraham> | HTML parsing pop quiz: |
| 09:29 | <jgraham> | <script>document.write("<plaintext>Filler"); document.close()</script> |
| 09:30 | <jgraham> | What does the DOM look like after document.close? |
| 09:30 | <wirepair> | broken? |
| 09:30 | <wirepair> | does broken count? :) |
| 09:31 | <jgraham> | No :) |
| 09:31 | <gsnedders> | Is it not just <plaintext>Filler? |
| 09:31 | <jgraham> | gsnedders: The theory is that it is not |
| 09:32 | <jgraham> | The theory might be wrong :) |
| 09:32 | <jgraham> | (biab) |
| 09:37 | <hsivonen> | jgraham: <html><head></head><body><plaintext>Filler</plaintext></body></html> |
| 09:37 | <hsivonen> | jgraham: (I didn't cheat. That is, I didn't actually try running your snippet.) |
| 09:39 | <abarth> | hum |
| 09:39 | <abarth> | no script tag? |
| 09:40 | <abarth> | seems like that would still be in the dom |
| 09:40 | <gsnedders> | Well, yeah. But I'm not convinced that's the interesting part. :P |
| 09:41 | <abarth> | i'm not sure whether we've properly handled all the document.close() cases |
| 09:41 | <hsivonen> | oh. I misread. I though the calling code was outside the document itself given .close() |
| 09:41 | <abarth> | especially with synchronous script execution with nested insertion points |
| 09:42 | <abarth> | exactly how synchronous it is is tricky |
| 09:42 | <abarth> | but this isn't one of those cases |
| 09:53 | <jgraham> | The theory is that the document.close() does nothing and, at the point it is called there is no <plaintext> in the DOM because EOF has not yet been reached |
| 09:55 | <jgraham> | (If this theory is true the results of nesting the whole construct inside a document.write of its own would be interestingly different) |
| 10:13 | <hsivonen> | jgraham: why wouldn't both the plaintext element and its child text node be already in the DOM at the point of calling .close()? |
| 10:13 | <hsivonen> | jgraham: I thought the spec changed to require that |
| 10:14 | <hsivonen> | jgraham: I expect it's even tested on html5test.com |
| 10:16 | <jgraham> | hsivonen: The theory could be wong, like I said, but I thought it only got emitted on EOF |
| 10:16 | <jgraham> | *wrong |
| 10:17 | <jgraham> | Oh, no, that seems right |
| 10:18 | <jgraham> | OK, so the original case I was looking at is more complex |
| 10:18 | <jgraham> | Maybe the more complex is needed |
| 10:18 | jgraham | goes spec hunting |
| 10:20 | <jgraham> | Right, I oversimplified |
| 10:21 | <jgraham> | Or.. |
| 10:21 | <jgraham> | More thinking less typing |
| 10:23 | <jgraham> | Right |
| 10:24 | <jgraham> | <script>document.write("<table><plaintext>Filler"); document.close()</script> was the original case |
| 10:24 | <jgraham> | more or less |
| 10:25 | <jgraham> | And in this case at the point of document.close the dom should have the <plaintext>, the <table> but *not* the string "Filler" |
| 10:32 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/673 |
| 10:35 | <zcorpan> | <table> is a neat way to make some content load later but appear earlier in the dom |
| 10:35 | <zcorpan> | too bad it's invalid to do that :) |
| 10:38 | <jgraham> | Where "neat" in this case mean "non-interoperable and weird" |
| 10:40 | <zcorpan> | it'll soon be interoperable |
| 10:41 | <zcorpan> | oooh 11 alpha |
| 10:45 | <othree> | http://addons.labs.opera.com/addons/extensions/ |
| 10:45 | <zcorpan> | hmm, wonder why the background and canvas examples don't work in opera in http://blog.dholbert.org/2010/10/svg-as-image.html |
| 10:45 | <othree> | sorry |
| 10:45 | <othree> | wrong channel |
| 11:27 | <annevk> | hello |
| 11:28 | <annevk> | still not published |
| 11:28 | <annevk> | hmm |
| 11:28 | <annevk> | later today? |
| 11:34 | <hsivonen> | Re: Shane's email, shouldn't one want spec writers to go all Hixie? |
| 11:58 | <zcorpan> | hsivonen: which email? |
| 12:01 | <jgraham> | hsivonen: I think "writing clear accurate specs" was not what he had in mind |
| 12:01 | <jgraham> | I'm not sure what he *did* have in mind though |
| 12:03 | <Philip`> | I assumed it was about him not advocating switching to an incompatible design that can be understood by more than 10 people in the world |
| 12:05 | <zcorpan> | ah, found link in the logs |
| 12:05 | <hsivonen> | yeah, I meant the link in the logs |
| 12:06 | <kuya> | hello, validators are telling me that im missing required attributes with `<style type="text/css">` - ive looked at the html5 spec but i dont see what im missing |
| 12:07 | <kuya> | any hints? |
| 12:07 | <Philip`> | It probably means you need to move it into your <head>, if I remember correctly |
| 12:07 | <kuya> | ahh i do have one not in the head ... |
| 12:07 | <Philip`> | (You can only use <style scoped> inside <body>, which is why it complains about the missing scoped attribute, I think) |
| 12:08 | jgraham | wonders if the scoped feature will survive |
| 12:08 | <hsivonen> | yes, the validator wants to see the scoped attribute |
| 12:08 | <hsivonen> | jgraham: I doubt it |
| 12:08 | <kuya> | thanks guys |
| 12:08 | <zcorpan> | the attribute that's missing is scoped="" (since you put the style in body) |
| 12:13 | <annevk> | almost flying time yay |
| 12:13 | <jgraham> | (but the problem is not that the attribute is missing, but that you put <style> in <body>) |
| 12:14 | <kuya> | yes it was a mistake from old code |
| 12:14 | <kuya> | didnt think i had any of those left |
| 12:44 | <MikeSmith> | so http://twitter.com/#!/hsivonen/status/28004974377 seems to imply you might be working on releasing a standalone version of the gecko/vnu HTML5 parser |
| 12:44 | <MikeSmith> | which would be very cool |
| 12:45 | <MikeSmith> | if that is in fact a goal |
| 12:46 | <jgraham> | hsivonen: libxml2 |
| 12:47 | <hsivonen> | MikeSmith: not working but planning without any promise or commitment or schedule |
| 12:48 | hsivonen | wonders what C or C++ people use to convert various encodings into UTF-8 |
| 12:48 | <MikeSmith> | hsivonen: OK, understood |
| 12:49 | <hsivonen> | libiconv looks surprisingly bad |
| 12:49 | <MikeSmith> | I was about to say… |
| 12:49 | <MikeSmith> | I think that is what most use |
| 12:49 | Philip` | handles XML in C++ via a system that first uses libxml2 to convert the XML to a custom binary format, and then the rest of the application uses a custom API to read that custom binary format |
| 12:49 | <jgraham> | hsivonen: Getting a real HTML parser into libxml2 would be amazingly awesome |
| 12:50 | <hsivonen> | it has the same API design error that causes Gecko to be unable to detect an incomplete byte sequence right before EOF in multibyte encodings |
| 12:50 | <hsivonen> | it being libiconv |
| 12:50 | <MikeSmith> | well, somebody should fix that |
| 12:50 | <hsivonen> | AFAICT, ICU converts to UTF-16 |
| 12:50 | <MikeSmith> | since iconv is in fact used all the hell all over the place |
| 12:51 | <hsivonen> | it's probably easier to fix Gecko's internal APIs than to fix the libiconv public API |
| 12:51 | <MikeSmith> | libxml2 does rely on iconv |
| 12:51 | <MikeSmith> | for example |
| 12:51 | <hsivonen> | (it's also possible that I have misunderstood the libiconv API) |
| 12:51 | <MikeSmith> | I think |
| 12:52 | <MikeSmith> | (I meant I think libxml2 relies on iconv) |
| 12:52 | <hsivonen> | MikeSmith: yeah, I guess there's no point in trying to fight libiconv if one isn't using ICU |
| 12:54 | <MikeSmith> | it may be that libiconv is broken by design that way |
| 12:54 | <MikeSmith> | just thinking out loud |
| 12:54 | <MikeSmith> | for compat of some kind |
| 12:55 | <MikeSmith> | I guess that large parts of the FOSS platform may also be in that state |
| 12:55 | <MikeSmith> | like the Web platform |
| 12:55 | <hsivonen> | indeed |
| 12:55 | <MikeSmith> | crap we are effectively stuck with forever |
| 12:55 | <Philip`> | Like commercial platforms too |
| 12:55 | <MikeSmith> | or for a long time at least |
| 12:55 | <MikeSmith> | Philip`: true |
| 12:55 | <MikeSmith> | that's a given |
| 12:56 | <zcorpan> | everything's crap, and we're stuck in it |
| 12:56 | <MikeSmith> | but that's their problem |
| 12:56 | <Philip`> | Like most non-computer-related platforms, too |
| 12:56 | <MikeSmith> | Philip`: such as? |
| 12:58 | <MikeSmith> | zcorpan: you have given me my translation target for the day |
| 12:58 | <Philip`> | Like TV, and electricity, and road systems, and book publishing, and all sorts of things, I guess |
| 12:58 | <hsivonen> | after university, I haven't written normal C or C++ code at all. I've been writing on top of all this Mozilla-specific infrastructure, so I don't really know how people really do stuff like stream io outside the Mozilla land |
| 12:59 | <hsivonen> | but I imagine no one really writes big apps in the io style shown in Stroustrup's book |
| 12:59 | <Philip`> | They're stuck with suboptimal designs because there's lots of interacting parties and it's too expensive to change them all at once |
| 13:00 | <MikeSmith> | I think DV addressed the broken dependency problem by reinventing a lot of wheels |
| 13:00 | <Philip`> | hsivonen: Most non-trivial projects seem to make up their own project-specific infrastructure, so there isn't any "normal" |
| 13:00 | <MikeSmith> | libxml2 seems to have a lot of stuff that it could be relying on libraries for |
| 13:02 | <MikeSmith> | wow |
| 13:02 | <MikeSmith> | zcorpan: Allt är skit, och vi är fast i den. |
| 13:02 | <MikeSmith> | zcorpan: does that sound natural? |
| 13:02 | <MikeSmith> | seems to round-trip at least |
| 13:04 | <MikeSmith> | oh |
| 13:04 | <MikeSmith> | wait |
| 13:04 | <MikeSmith> | "stuck _in_ it" |
| 13:04 | <MikeSmith> | hmm |
| 13:04 | <MikeSmith> | not quite the same at all |
| 13:04 | <MikeSmith> | though still a good sentiment |
| 13:06 | <Philip`> | Good C++ library design usually seems to involve having as few dependencies as possible, to minimise friction with whatever crazy infrastructure is already used in projects |
| 13:06 | <Philip`> | e.g. don't use any libraries for IO (even standard iostreams), just let the application provide a simple callback function |
| 13:07 | <Philip`> | (then add an extra layer of convenience API that takes a filename and does sensible default behaviour) |
| 13:08 | <hsivonen> | it seems to me that java.io and org.xml.sax have a lot of value even when they suck |
| 13:10 | <Philip`> | Yeah, C++ is pretty rubbish at having standard ways to do simple things like that |
| 13:10 | <Philip`> | You can't even write a library that uses standard new/delete without some applications considering it unacceptable and requiring a way to override the behaviour |
| 13:12 | <MikeSmith> | Philip`: I realize my previous experiences in working on proprietary commercial software does exhibit exactly what you describe |
| 13:13 | MikeSmith | worked a lot at one time on product dev or e-mail infrastructure - MTA, message store, DB interfaces, congestion control stuff, related ldap server, other stuff |
| 13:14 | <MikeSmith> | somebody should write a book about this |
| 13:14 | <MikeSmith> | along the lines of Mythical Man Month |
| 13:15 | hsivonen | notes that Gecko supplies its own malloc on Windows and Linux and then puts a customized operator new on top of it |
| 13:15 | <MikeSmith> | when I worked we used some third-party malloc |
| 13:15 | <MikeSmith> | which we had licensed |
| 13:15 | MikeSmith | tries to remember the name |
| 13:16 | <MikeSmith> | very common one |
| 13:16 | <MikeSmith> | but it was a give that using the platform malloc was a non-starter |
| 13:16 | <MikeSmith> | *given |
| 13:16 | <hsivonen> | Mozilla uses jemalloc |
| 13:16 | <hsivonen> | isn't Lea malloc the other one people like to use? |
| 13:21 | <MikeSmith> | SmartHeap is what we used |
| 13:21 | <MikeSmith> | I think |
| 13:22 | <MikeSmith> | actually, we had our own branch of it |
| 13:22 | <MikeSmith> | that we maintained as part of our code |
| 13:22 | <MikeSmith> | we licensed in and forked it basically |
| 13:22 | <MikeSmith> | further example of the phenomenon Philip` was describing |
| 13:56 | <hsivonen> | I'd love to see some kind of tutorial that explains the memory management options for local name strings in the libxml2 DOM |
| 14:01 | <rubys> | hsivonen: cool to see you interested in libxml2; I may be able to help starting mid next month |
| 14:04 | <hsivonen> | rubys: to set expectations correctly: I'm just trying to find out what steps are required. I don't promise to take those steps at any particular schedule or at all. |
| 14:05 | <hsivonen> | rubys: of course, it would be awesome if you did :-) |
| 14:06 | <hsivonen> | I'm rather surprised that neither libxml2 nor Xerces C++ has a special interned type for local names |
| 14:06 | <hsivonen> | both Gecko and WebKit do interning around this area |
| 14:07 | <hsivonen> | hmm. I see that libxml2 docs say something about a dict for names |
| 14:07 | <hsivonen> | maybe there's optional interning or something? |
| 14:08 | <rubys> | I do a lot of HTML parsing. Example which helps me keep track of issues and bugs: http://intertwingly.net/stories/2010/10/21/libxml2-html5-test.rb |
| 14:08 | <rubys> | wrong link |
| 14:08 | <rubys> | http://intertwingly.net/stories/2010/10/21/wgstatus.rb |
| 14:08 | <rubys> | example output: http://intertwingly.net/stories/2010/10/21/wgstatus.html |
| 14:09 | <rubys> | of course, that depends on being able to parse HTML, and most of the HTML I parse is "mostly" clean |
| 14:09 | <karlcow> | ooooh http://developer.apple.com/library/mac/#releasenotes/Java/JavaSnowLeopardUpdate3LeopardUpdate8RN/NewandNoteworthy/NewandNoteworthy.html#//apple_ref/doc/uid/TP40010380-CH4-DontLinkElementID_2 |
| 14:09 | <hsivonen> | I'm also surprised at how few word are used to talk about the memory management / object ownership considerations in the libxml2 docs |
| 14:09 | <karlcow> | "As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated." |
| 14:09 | <rubys> | back to the link I incorrectly posted at first, that is a test of the parser, and here is output: http://intertwingly.net/stories/2010/10/21/libxml2-html5-test.out |
| 14:10 | <rubys> | not all of those differences are problems, but most are |
| 14:10 | <hsivonen> | makes me wonder if I'm clueless and libxml2 DOM memory management is obvious for everyone else |
| 14:10 | <rubys> | http://xmlsoft.org/xmlmem.html |
| 14:12 | <hsivonen> | rubys: that page doesn't really explain if its possible to share local name memory between nodes and such |
| 14:13 | <rubys> | Author of libxml2 seems active: http://mail.gnome.org/archives/xml/2010-October/thread.html |
| 14:14 | <rubys> | look for Daniel Veillard |
| 14:14 | <hsivonen> | of course, the easy way would be not to care and use the node creator that always copies the local name |
| 14:15 | <rubys> | +1 |
| 14:15 | <rubys> | get it working, and then fix the problems that are real problems later |
| 14:15 | <smaug____> | hsivonen: just wondering, what are you doing? |
| 14:17 | <hsivonen> | smaug____: I'm looking at the libxml2 tree API to get an idea what it would take to target the Java to C++ translator to target libxml2 in addition to targeting NSPR/Gecko |
| 14:18 | <smaug____> | hsivonen: ah, so the idea is that libxml2 could support html5 parsing |
| 14:19 | <hsivonen> | smaug____: the idea is the have a library that does HTML5 parsing and is API-compatible with libxml2 |
| 14:20 | <hsivonen> | (maybe sometime in the future when Firefox 4 has shipped, etc.) |
| 14:20 | <hsivonen> | with emphasis on "maybe" |
| 14:21 | <zcorpan> | MikeSmith: Allt är skit, och vi sitter fast i det |
| 14:22 | <MikeSmith> | zcorpan: thanks |
| 14:22 | MikeSmith | tweets |
| 14:23 | <hsivonen> | first I was inclined to correct MikeSmith with s/den/det/ but then I figured 'den' was right. But apparently 'det' would have been right anyway. |
| 14:23 | MikeSmith | remembers now that hsivonen speaks Swedish too |
| 14:23 | <hsivonen> | MikeSmith: for *very* small values of "speak" |
| 14:24 | <MikeSmith> | heh |
| 14:24 | <smaug____> | all the Finns speak Swedish, well at least a bit |
| 14:26 | jgraham | had a notion that s/den/det/ was better but has embarassingly bad Swedish |
| 16:15 | <annevk> | so a new ARIA document is published... |
| 16:15 | <annevk> | I'm still waiting for answers to my previous series of comments |
| 16:23 | <annevk> | hsivonen, http://i.imgur.com/51f9p.jpg is great |
| 16:33 | <Workshiva> | annevk: And the truth |
| 19:21 | Ms2ger | just found http://www.w3.org/Style/css2-updates/russian/Overview.html |
| 20:09 | <Ms2ger> | Look, someone found a bug in XHTML1 |
| 20:09 | <JonathanNeal> | "To be or not to be" - William Shakespeare ... what is the proper HTML5 markup for this? |
| 20:10 | <JonathanNeal> | I used to think it was blockquote+cite, but based on #the-blockquote-element in the spec it would seem not to be. Anyone around here know? |
| 20:11 | <Hixie_> | <p><q>To be or not to be</q> - William Shakespeare ... what is the proper HTML5 markup for this?</p> |
| 20:11 | <JonathanNeal> | Williams Shakespeare does not receive a cite, all right. |
| 20:11 | <Hixie> | a cite? |
| 20:11 | <JonathanNeal> | Yes, a cite, #the-cite-element |
| 20:12 | <Hixie> | ah, correct. <cite> is for titles of works. |
| 20:13 | <Ms2ger> | Yay for bruce muddling the waters again |
| 20:13 | <JonathanNeal> | not for authors? got it. |
| 22:16 | <AryehGregor> | So it turns out bidi is complicated. |
| 22:16 | <zcorpan> | let's go shopping! |
| 22:19 | <Hixie> | AryehGregor: no kidding |
| 22:19 | <Hixie> | what made you realise that? |
| 22:19 | <AryehGregor> | Aharon's comments on the dir=auto thing. |
| 22:19 | <AryehGregor> | I'll have to take some time to read them carefully. |
| 22:20 | <AryehGregor> | I'm pretty sure his proposal isn't ideal, but I doubt mine is so great either. |
| 22:20 | <Hixie> | ah |
| 22:20 | <Hixie> | i wish those bugs started from use cases rather than proposals |
| 22:21 | <Hixie> | though we seem to be getting better on that front now |
| 22:21 | <AryehGregor> | This is what you get from task forces. |
| 22:23 | <jgraham> | The word "tak force" always makes me think that camouflage paint should be involved somewhere |
| 22:23 | <jgraham> | *task |
| 22:29 | <annevk> | "Task Force" always reminds me of the route we did not take |
| 22:30 | <AryehGregor> | Okay, my number-one desired feature right now is that browsers sync history and passwords and stuff between different vendors' browsers. |
| 22:30 | <AryehGregor> | Is anyone interested in that, like, at all? |
| 22:40 | <jgraham> | AryehGregor: define "anyone" |
| 22:41 | <AryehGregor> | "anyone who actually stands a chance of encouraging it to happen" |
| 22:41 | <othermaciej> | AryehGregor: there's probably not a lot of people who use browsers from different vendors regularly |
| 22:42 | <othermaciej> | so I suspect there is not a lot of demand |
| 22:42 | <jgraham> | annevk: Well you it is disappointing that the reality often seems to be less "action man" and more "paralysed by self-imposed bureaucracy man" |
| 22:42 | <AryehGregor> | Tons of people use IE at work and some other browser at home. |
| 22:42 | <AryehGregor> | Also, it would let people try out other browsers more easily, that's the real point. |
| 22:42 | <jgraham> | othermaciej: I believe something called XMarks did this |
| 22:43 | <AryehGregor> | So if I want to try out Firefox 4, I don't have to be constantly distracted by having to go look up my login info. |
| 22:43 | <AryehGregor> | (which is stored in Chrome) |
| 22:44 | <jgraham> | AryehGregor: It seems like a hard problem and even harder to convince browser vendors to implement |
| 23:02 | <gsnedders> | jgraham: Yeah, but years of experience tell me that by the time I get close enough to the photos (or more normally, they get close enough to me), it's August and I don't care any more |
| 23:24 | <AryehGregor> | jgraham, why is it much harder than intra-browser sync? |
| 23:25 | <AryehGregor> | The stuff you're syncing is essentially the same cross-browser, no? |
| 23:25 | <Hixie> | it's hard for intra-browser too |
| 23:25 | <AryehGregor> | Well, yes, but clearly that's not *too* hard. |
| 23:28 | <Hixie> | it's difficulty^N harder to get N browsers to do it in a compatible way |
| 23:28 | <Hixie> | (ok i pulled that out of my behind, but the idea is sound) |
| 23:29 | <Hixie> | it's even harder than normal since the user benefit is low so it's unlikely anyone will care enough to write a spec, etc8 |
| 23:30 | <AryehGregor> | On the other hand, if this were widely supported, browsers could scrap their code for importing all this stuff from other browsers, which they currently all have to write anyway. |
| 23:31 | <AryehGregor> | And that's surely even more annoying and fragile, because they have to reverse-engineer the other browser's storage formats. |
| 23:31 | <Hixie> | *shrug* |
| 23:32 | <Hixie> | write a spec, get browsers to implement |
| 23:32 | <AryehGregor> | I know the procedure. |
| 23:32 | <Hixie> | :-) |
