| 00:21 | <Hixie> | annevk: yt? |
| 01:51 | <Hixie> | huh |
| 01:51 | <Hixie> | there's exactly one IDREFS attribute in HTML4 |
| 01:51 | <Hixie> | how annoying |
| 01:59 | <Hixie> | http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02996.pdf may be the reason behind microsoft's proposal against XXX |
| 02:00 | <Hixie> | or at least, that mindset |
| 02:07 | <Philip`> | "... CSS (which is essentially an IE-specific feature)" - I'm glad it's no longer 1998 and there's more than one decent browser |
| 02:17 | <othermaciej> | certainly no one would call CSS an IE-specific feature nowadays |
| 06:36 | <annevk> | Hixie, am now |
| 06:51 | <annevk> | omg, the Microsoft stream of FUD continues |
| 06:52 | <annevk> | http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0043.html |
| 07:07 | <hsivonen> | http://lists.w3.org/Archives/Public/public-xhtml2/2008Mar/0036.html |
| 07:09 | <webben> | wha? |
| 07:09 | <webben> | I wonder if he's only talking about 1.1 revisions |
| 07:10 | <hsivonen> | webben: I pretty sure he is talking more generally |
| 07:10 | <othermaciej> | does Sunava not understand what the word "specific" means? |
| 07:11 | <othermaciej> | annevk: I'm pretty tired of repeatedly asking for a description of a specific vulnerability |
| 07:12 | <othermaciej> | annevk: do you think they really have one? |
| 07:12 | <webben> | can TBL not sort this out one way or the other? ; we can't both have HTML5 defining how to process a the XHTML1 namespace and text/html and XHTML2 using the same namespace (they're still doing that, are they not) and trying to subset text/html. |
| 07:13 | <annevk> | I have the feeling it's a bunch of FUD and Microsoft doesn't try very hard to provide proof to the contrary |
| 07:13 | <hsivonen> | webben: be careful what you ask for when it comes to sending issues to TAG |
| 07:13 | <othermaciej> | it could just be that Sunava is not a very good analyst or communicator |
| 07:21 | <annevk> | Yeah, could be. I believe he's a manager and doesn't work on the code himself. |
| 08:06 | <Hixie> | webben: i wouldn't worry about it |
| 08:07 | <Hixie> | webben: if it's impossible to implement both html4/xhtml1 and xhtml2 at the same time (as will be the case if xhtml2 continues along its present vector) then the issue of whether browsers should implement xhtml2 or not will be neatly solved. |
| 08:18 | <Hixie> | hodeehum, the idrefs problem isn't such a big problem after all |
| 08:29 | <annevk> | which idref problem? |
| 08:42 | <hsivonen> | http://realtech.burningbird.net/standards/joel-spolsky-crap-is-good/ |
| 08:48 | annevk | looks forward to “Standards are tough! Let’s go shopping!” |
| 08:48 | <othermaciej> | shopping is tough |
| 08:49 | <hsivonen> | indeed. with all the Flash in the way of mobile shopping support use cases |
| 08:50 | <roc> | annevk: http://ejohn.org/blog/getboundingclientrect-is-awesome/ |
| 08:51 | <vlad_> | yes, it's very awesome |
| 08:53 | <hsivonen> | I think what Joel is missing is what Dean Edwards points out: today the Web works without IE |
| 08:53 | <hsivonen> | the IE legacy is now hurting IE8--not helping it |
| 08:53 | Hixie | finds suspicious &-related syntax in office open xml that may in fact be non-xml |
| 08:53 | Hixie | investigates |
| 08:54 | hsivonen | notes that OOXML can store non-XML Char code points in a really ugly and inefficient way but doesn't explain the semantics of those code points when found in a document |
| 08:56 | <roc> | because of their "embed the legacy engine" technique, the IE legacy is going to hurt them forever |
| 08:58 | <hsivonen> | given the current Web environment (intranets and CD-ROM are not part of the Web), modeling the way Safari entered the market would seem like smarter move |
| 09:00 | <hsivonen> | is cross-site XHR in Firefox 3 dead for good or is the issue still up in the air? |
| 09:01 | <Pavlov> | pretty dead |
| 09:01 | <roc> | looks pretty dead |
| 09:01 | <Pavlov> | working group took too long ;( |
| 09:01 | <hsivonen> | :-( |
| 09:01 | <Hixie> | actually it is dead because dveditz and a couple of other people were scared to send cookies with the request |
| 09:01 | <annevk> | roc, cool, any updates on ClientRect.width/height? :) |
| 09:01 | <Hixie> | (not because the working group "took too long") |
| 09:02 | <roc> | annevk: not really on my list for 1.9 |
| 09:02 | <annevk> | kk |
| 09:02 | <Pavlov> | Hixie: it was getting cut because of the working group taking too long |
| 09:02 | <roc> | which doesn't really matter since IE doesn't have them so authors have to be able to deal with that anyway |
| 09:02 | <roc> | for now |
| 09:02 | <annevk> | Pavlov, no, that was not the primary reason |
| 09:02 | <Pavlov> | um |
| 09:02 | <Pavlov> | i sit next to jonas? |
| 09:02 | <Pavlov> | the nail in the coffin was security |
| 09:02 | <annevk> | Pavlov, also, if the WG took too long that's because Mozilla was asking for changes when we thought we were almost done |
| 09:03 | <vlad_> | er, I thought the issue was the opposite |
| 09:03 | <vlad_> | that we thought that we were done, but that the wg was asking for changes |
| 09:03 | <hsivonen> | hmm. I guess the "Ajax mashup" aspect of Validator.nu is then dead is the XTech timeframe :-( |
| 09:03 | <vlad_> | not being able to come to consensus about the cookie issues was definitely the nail in the coffin, though |
| 09:04 | <vlad_> | (even though I still think that we should just send cookies, because it's not any different than what the web does today for all sorts of stuff) |
| 09:04 | <othermaciej> | I'm surprised cross-site XHR is dropped, but at least there is postMessage for controlled cross-site communication |
| 09:04 | <othermaciej> | which should be available in a cross-browser way soon |
| 09:04 | <Pavlov> | annevk: everyone really wanted it in, which is the only reason it got cut so late |
| 09:04 | <Pavlov> | it should have been cut much earlier |
| 09:04 | <vlad_> | othermaciej: yeah, that was presented as a viable alternative |
| 09:04 | <annevk> | it's still in nightlies afaict |
| 09:04 | <hsivonen> | It sucks that now IE8 can be the first-mover in scripted cross-site requests |
| 09:05 | <vlad_> | hsivonen: well, you can emulate things with postMessage pretty well |
| 09:05 | <othermaciej> | it can't be the first mover in a beta release |
| 09:05 | <Hixie> | yeah, if firefox3 doesn't ship with xhr done right, we may well be presented with the microsoft treadmill in the form of their xdr nonsense |
| 09:05 | <othermaciej> | whether it will be first in a non-beta remains to be seen |
| 09:05 | <annevk> | Pavlov, the WG did make some changes, but every change I've made sure Jonas was ok with it; Jonas himself also requested several simplifications that he had already implemented |
| 09:05 | <vlad_> | Hixie: yeah, at this point fx3 won't =/ |
| 09:05 | <vlad_> | whatever's next certainly will, though |
| 09:06 | <Hixie> | vlad_: yeah, it's sad. might be more expensive for mozilla (and the other vendors) on the long run. luckily for me, xhr isn't my problem any more :-) |
| 09:06 | <hsivonen> | vlad_: I had a RESTful Web service API design. It wasn't designed for Firefox. Access-control made it easy for me to CS-XHR-enable it my editing one servlet class |
| 09:06 | <vlad_> | hsivonen: I agree |
| 09:06 | <vlad_> | I quite liked the XD-XHR model |
| 09:06 | <hsivonen> | vlad_: with postMessage, I now would have to serve up an iframeable JS API specifically |
| 09:07 | <vlad_> | right |
| 09:07 | <vlad_> | like I said, the final issue was the cookies problem |
| 09:07 | <annevk> | It's too bad people always refer to it as cross-site XMLHttpRequest while it also enables cross-site XSLT, XBL, <event-source>, etc. |
| 09:07 | <vlad_> | because you're damned if you do and damned if you don't |
| 09:07 | <Hixie> | vlad_: convince dveditz to change his mind :-) |
| 09:08 | <hsivonen> | moreover, for moving a DOM tree across postMessage will suck big time |
| 09:08 | <vlad_> | Hixie: afaik, we did, but it was already too late to change back (again) |
| 09:08 | <Hixie> | i suppose if ff3 ships soon enough, mozilla could switch to a more rapid dev cycle and release ff3.1 before ie8 comes out |
| 09:08 | <Hixie> | (a more rapid dev cycle would solve several problems mozilla is having) |
| 09:08 | <annevk> | you changed his mind and now it's too late? :( |
| 09:08 | <annevk> | man, that's a sad story |
| 09:09 | <vlad_> | annevk: nah, life goes on |
| 09:09 | <vlad_> | it's not the last firefox release :p |
| 09:09 | <vlad_> | I also made an argument that perhaps the spec should handle cookies explicitly |
| 09:09 | <Hixie> | might be the last one this decade though :-P |
| 09:09 | <vlad_> | and require sites to indicate whether they want cookies or not |
| 09:09 | <annevk> | I'm glad I hear all this just before I leave for a long weekend in Spain |
| 09:09 | <Pavlov> | Hixie: very very very doubtful |
| 09:10 | <hsivonen> | I guess I'll send email about the Validator.nu scenario in response to XDR, though |
| 09:11 | <vlad_> | zzz time |
| 09:11 | <Hixie> | Pavlov: i hope you're right |
| 09:12 | <Hixie> | but there's less than 2 years left this decade, and that doesn't leave long for a whole cycle at the current rate |
| 09:12 | <sayrer> | the next one will be faster |
| 09:12 | <roc> | everyone knows that 2010 is part of this decade |
| 09:12 | <sayrer> | in fact, several of the features are already done :) |
| 09:13 | <Hixie> | that's what was said after 1.5 and after 2.0, too :-) |
| 09:13 | <sayrer> | things are different now |
| 09:13 | <roc> | 2.0 WAS a fast cycle |
| 09:14 | <Hixie> | ah, my memory must be failing me. it was so long ago. :-P |
| 09:14 | <Pavlov> | 2-3 wasn't that long of a cycle either, really, except for those of us who were working on it for 1.5 years before everyone else |
| 09:14 | <Pavlov> | :/ |
| 09:15 | <Hixie> | (btw https://bugzilla.mozilla.org/show_bug.cgi?id=408098 doesn't at all convey the cutting of xxx as being a done deal, other than in the flags) |
| 09:15 | <Pavlov> | a little long |
| 09:15 | <sayrer> | main problem was the planning process |
| 09:15 | <Pavlov> | Hixie: yeah, we stoppe dtaking -'d things last week |
| 09:15 | <sayrer> | in that we had one |
| 09:16 | <sayrer> | what a waste of time |
| 09:16 | Pavlov | rolls his eyes at sayrer |
| 09:18 | <sayrer> | yes, I would like to change my position. Pavlov is right. The Firefox 3 planning process was a great success. |
| 09:19 | <Pavlov> | it turned out pretty well i'd say |
| 09:20 | <sayrer> | except for all time we wasted on irrelevant shit |
| 09:20 | <Pavlov> | like? |
| 09:20 | <Pavlov> | i'm pretty sure I haven't wasted any time on "irrelevant shit" in the last 3 years |
| 09:20 | <sayrer> | I don't think you did |
| 09:21 | <Pavlov> | and i can say that planning out much of the thigns i did was useful |
| 09:21 | <sayrer> | we also landed like 2 megs of security theater code in NSS |
| 09:21 | <sayrer> | as planned! |
| 09:21 | <Pavlov> | so, if you want to give the UI guys crap go for it |
| 09:23 | <sayrer> | no, it takes a village for something like that |
| 09:23 | <Pavlov> | i don't think so. specifically the platform team took a very different approach to planning than the frontend team did |
| 09:27 | <roc> | now now |
| 09:28 | Philip` | notices that http://www.joelonsoftware.com/items/2008/03/17.html appears to have quite good <img alt> text |
| 09:49 | <shepazu> | Hixie: http://www.viruscomix.com/page433.html |
| 10:52 | <hsivonen> | shepazu: the science guy looks like Dawkins but who are the other three faces? |
| 10:57 | <shepazu> | hsivonen: I think the last guy may be Hitchens |
| 10:59 | <hsivonen> | shepazu: could be, yeah |
| 11:01 | <roc> | wild guess: Hitchens, Dawkins, Dennett, and Harris |
| 11:03 | <hsivonen> | roc: thanks |
| 11:27 | <shepazu> | lol... funny that roc would be the one to know it :) |
| 11:27 | <shepazu> | that's irony for you |
| 11:32 | <roc> | of course I'm interested in their activities :-) |
| 12:25 | <hsivonen> | wow. a Danish bank manages to be even more idiotic about Web banking than American or Korean banks: |
| 12:25 | <hsivonen> | Danske Bank acquired Sampo Pankki |
| 12:26 | <hsivonen> | then proceeded to switch the Web bank UI to require client-side Java |
| 12:26 | <hsivonen> | the result doesn't work for thousands of customers |
| 12:26 | <hsivonen> | do these bank system architects live in 1995 or something? |
| 12:26 | <zcorpan> | lol |
| 12:27 | <Dashiva> | They're used to mainframe systems :) |
| 12:27 | <Camaban> | it *works* for them, thereofre it must work for everyone else ;) |
| 12:28 | <hsivonen> | the other banks operating in Finland have Web banks that work on just about anything from Lynx to random mobile devices |
| 12:32 | <didymos> | hsivonen, oh yeah, but Danske Bank's solution is very secure! |
| 12:32 | <didymos> | sigh |
| 12:33 | <shepazu> | hsivonen: you assume this was an accident |
| 12:33 | <shepazu> | perhaps Denmark is preparing an invasion of Finland? |
| 12:34 | <didymos> | shepazu, we have a plan in the making |
| 12:34 | <shepazu> | I would see the use of Java as a hostile act, certainly |
| 12:34 | <didymos> | shepazu, yeah, maybe someone ought to attack Denmark to free us from Java |
| 12:35 | <Camaban> | not an invasion, a liberation? :) |
| 12:35 | <shepazu> | you could print a cartoon of Mohammed drinking a cup of coffee under a shining Sun, and have the terrorists take care of the problem |
| 12:35 | <hsivonen> | didymos: reportedly, they use an outdated server version... |
| 12:36 | <shepazu> | jihad on Sun Microsystems!!! |
| 12:36 | <shepazu> | or fatwa, maybe |
| 12:37 | <Camaban> | ah, surely using client side java is jsut the pragmatic solution, all this cross browser stuff is too idealistic |
| 12:38 | <virtuelv> | Camaban: yeah, like even sun isn't doing |
| 12:38 | <virtuelv> | the front page of java.com uses Flash, but no Java |
| 12:38 | <Camaban> | heh |
| 12:39 | <virtuelv> | hsivonen: my old bank used to have a Lynx-compatible solution |
| 12:39 | <virtuelv> | these days, I need a stupid java applet to log in |
| 12:43 | <hsivonen> | virtuelv: that sucks. how can they stay in business with stuff like that? |
| 12:43 | <hsivonen> | surely there are other Norwegian banks with clue? |
| 12:44 | <virtuelv> | hsivonen: I think most of them require Java for the login these days |
| 12:44 | <Dashiva> | Not postbanken! |
| 12:44 | Dashiva | dances |
| 12:44 | <virtuelv> | Dashiva: are you still using one-time code pads then? |
| 12:45 | <Dashiva> | Yes |
| 12:45 | <virtuelv> | that's what my local bank used to do as well |
| 12:45 | <hsivonen> | hmm. with my bank, the top compat problem is that they are scared of Opera acting as a man-in-the-middle with Mini, so they block Mini even though they otherwise allow browser choice |
| 12:45 | <virtuelv> | now they switched to Bank-ID and that RSA-gadget |
| 12:46 | <Dashiva> | I don't get why they voluntarily reduce security like that |
| 12:46 | <hsivonen> | a one-time pad of pass numbers works great |
| 12:46 | <hsivonen> | no special hardware required |
| 12:46 | <didymos> | Dashiva, because it has fancy acronyms |
| 12:46 | <hsivonen> | works even over a phone interface |
| 12:46 | <hsivonen> | secure |
| 12:46 | <Dashiva> | "Something you have, something you know" |
| 12:46 | <hsivonen> | all these hardware dongles are dumb |
| 12:46 | Philip` | hasn't encountered any UK banks with anything other than an HTML form asking for password and PIN number (or a random selection of letters/digits from them) |
| 12:47 | <hsivonen> | Philip`: didn't Barclay's just introduce something incredibly stupid? |
| 12:47 | <hsivonen> | hendry has blogged about it |
| 12:48 | <Camaban> | Lloyds ask for a number, a password, and a random selection of characters from a 'memorable word' |
| 12:48 | <Philip`> | hsivonen: I've heard people talking in the past few days about getting card reader devices from various banks, so I guess they're changing now |
| 12:49 | jgraham__ | has been told that some kind of number-entering keypad device thing is being rolled out |
| 12:49 | <virtuelv> | if my bank switches to hardware I actually have to attach to my computer, I'll switch |
| 12:49 | <Philip`> | http://www.barclays.co.uk/pinsentry/ |
| 12:49 | <Philip`> | I've seen someone with a similar thing from Nationwide |
| 12:49 | <virtuelv> | the RSA gadget I have just has a button and displays random digits |
| 12:50 | <Philip`> | Also http://natwest.com/reader |
| 12:50 | <jgraham__> | http://www.nationwide.co.uk/rca/Introduction/why.htm |
| 12:52 | <Philip`> | It seems like quite a coordinated action between all the banks |
| 12:52 | <Philip`> | since I don't think I'd heard of any of this a month ago |
| 12:52 | jgraham__ | isn't quite sure what type of attack this is designed to mitigate |
| 12:53 | <hsivonen> | it mitigates mobile use of banking when the dongle is too inconvenient to carry |
| 12:53 | <virtuelv> | jgraham__: replay attacks |
| 12:53 | <Philip`> | Sounds like it requires you to physically have the card, rather than merely knowing the password |
| 12:53 | <virtuelv> | it also mitigates the use on infected computers |
| 12:54 | hsivonen | thought the low-tech one-time pad mitigated replay attacks especially if the pad is needed both for login and trasaction confirmation |
| 12:54 | <virtuelv> | it does |
| 12:54 | <Philip`> | (Also sounds like it's only for certain relatively rare actions, like setting up a new third party payment, and not for normal logging in and checking balances and sending payments and whatever) |
| 12:55 | <virtuelv> | so there is no added benefit over the one-time pad, but these solutions are cheaper |
| 12:55 | <hsivonen> | on a completely different topic: if browsers know about an unregistered charset x-foo, do they always also recognize foo in case it gets registered later? |
| 12:55 | <svl> | We've had similar card-readers for internet banking in the Netherlands for years. |
| 12:55 | <svl> | No passwords at all - just the pin for your debit card to generate a response to the constantly changing challenges. |
| 12:55 | <hsivonen> | virtuelv: how is a hardware dongle cheaper than a piece of paper? |
| 12:56 | <virtuelv> | hsivonen: when I was using the one-time pads, I had to have them shipped about 12 times a year |
| 12:56 | <svl> | Needed for logging in, and making transactions or adding accounts to your address book - and then an additional time if the transaction is higher than x-thousand euro. |
| 12:56 | <hsivonen> | I get a new one about once or twice a year |
| 12:57 | <hsivonen> | I guess I'm not a heavy user of banking |
| 12:57 | <hsivonen> | the bank sends me other paper mail much more often |
| 13:01 | jgraham__ | wonders if fake card readers that e.g. steal your pin will begin to appear |
| 13:01 | <Dashiva> | I'm still on my first onetime pad |
| 13:02 | <svl> | jgraham__: how would they transmit the pin? |
| 13:03 | <Philip`> | You could just reuse the one-time pad if it runs out too quickly |
| 13:04 | <jgraham__> | svl: I don't know; I'm not really sure what the possibilities are (or the requirements for successful fraud) |
| 13:04 | <Philip`> | http://www.cl.cam.ac.uk/research/security/banking/ped/ made people a bit unhappy about Chip & PIN |
| 13:06 | <Philip`> | (Also http://www.cl.cam.ac.uk/research/security/banking/tamper/tetris.jpg playing Tetris on a 'tamper resistant' PIN-entry terminal) |
| 13:09 | <hsivonen> | one-time pads can easily be made to have tamper evidence even if resistence would be hard |
| 13:25 | <hsivonen> | http://mxr.mozilla.org/seamonkey/source/intl/uconv/src/charsetalias.properties is sad reading |
| 13:25 | <hsivonen> | "x-x-big5 is not really a alias for Big5, add it only for MS FrontPage |
| 13:25 | <hsivonen> | " |
| 13:33 | <hsivonen> | is there an MXR kind of thing for WebKit? |
| 13:33 | hsivonen | finds http://trac.webkit.org/projects/webkit/browser |
| 13:37 | <hsivonen> | does WebKit rely purely on ICU charset alias data? or is there a layer of Web reality craziness somewhere? |
| 13:46 | <Philip`> | hsivonen: http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/text/TextCodecICU.cpp#L110 |
| 13:46 | <Philip`> | plus some other TextCodec* files |
| 13:53 | <hsivonen> | Philip`: thanks |
| 13:54 | <hsivonen> | "xxbig5" I wonder if WebKit or the pre-ICU lib removed hyphens before doing alias matching |
| 13:59 | hsivonen | smiles at #include <wtf/unicode/Unicode.h> |
| 14:07 | <hsivonen> | who actually uses "x-user-defined"? |
| 14:09 | <Philip`> | http://philip.html5.org/data/charsets.html#charset-x-user-defined |
| 14:13 | <hsivonen> | it seems to me that ICU and IANA are failing if both WebKit and Validator.nu HTML parser end up needing an ICU fooling layer |
| 14:14 | <Philip`> | It's only failing if its goal is to be compatible with broken web content |
| 14:37 | Philip` | tries that chardet thing |
| 14:42 | <Philip`> | Uh, it says it's finding a lot of UTF-16, which is odd because there isn't any |
| 14:45 | <Philip`> | It doesn't seem especially reliable at detecting encodings |
| 14:46 | <hsivonen> | Philip`: have you tried the ICU detector? is it any better? |
| 14:46 | <hsivonen> | (not that it matter since Mozilla chardet is the de facto standard that gets ported to Python, Java, etc.) |
| 14:46 | <Philip`> | I'm not sure how to judge betterness |
| 14:47 | <Philip`> | http://philip.html5.org/data/chardet-bytes.svg is how many bytes jchardet takes before making a decision |
| 14:48 | <Philip`> | (In about 85% of cases where it makes a decision, it makes the decision before reaching the end of the document) |
| 14:49 | <Philip`> | (i.e. this isn't just a graph of page length) |
| 14:49 | <hsivonen> | thank you. |
| 14:49 | <hsivonen> | those numbers look rather discouraging |
| 14:49 | <hsivonen> | I was hoping to see almost definite answers after 2 KB or 4 KB |
| 14:51 | <hsivonen> | did you test involve letting chardet decide when it is fully confident or did you measure how much data it needs not to actually change its mind? |
| 14:58 | <Philip`> | I just recorded how many bytes I had to give it until it first made a decision (returned true from DoIt(...)) |
| 14:59 | <Philip`> | (passing in a single byte at a time) |
| 14:59 | <hsivonen> | but not fooling the stream ended, I presume? |
| 15:00 | <Philip`> | (since it splits n byte buffers into effectively n 1-byte calls, so it doesn't mind how much you give it at once, unless I'm horribly mistaken) |
| 15:00 | <Philip`> | No |
| 15:01 | <Philip`> | so there would be different results if you gave it 4KB and then called Done() |
| 15:02 | <Philip`> | (I could try it with something like that, but I think only for a small predefined set of buffer sizes) |
| 15:02 | <hsivonen> | perhaps trying with 512 byte increments would make sense |
| 15:03 | <Philip`> | (Also the set should be finite) |
| 15:03 | <Philip`> | 512 byte increments up to 4KB? |
| 15:04 | <hsivonen> | that would be good |
| 15:06 | <Philip`> | Should I record whether it makes any decision at all, or whether it makes the same decision as with the entire buffer? |
| 15:06 | <hsivonen> | whether it makes the same decision as with the entire buffer seems to be the right thing to measure |
| 15:07 | <Philip`> | Including cases where it never makes any decision at all? |
| 15:08 | <hsivonen> | yeah |
| 15:14 | <Philip`> | It's pretty indecisive on http://www.trivus.com |
| 15:14 | <Philip`> | 512 bytes, 1024, 1536: Big5 |
| 15:14 | <Philip`> | 2048: GB18030 |
| 15:14 | <Philip`> | 2560: Shift_JIS |
| 15:14 | <Philip`> | 3072: Big5 |
| 15:14 | <Philip`> | 3584, ...: GB18030 |
| 15:14 | <Philip`> | (Correct answer: iso-8859-1) |
| 15:18 | <hsivonen> | ouch |
| 15:30 | <Philip`> | So... For each length 'n', I'm counting the number of pages which, when prefixes of length (n, n+512, n+1024, ...) (actually not really that sequence, but similar) are chardetted, consistently give the same answer (including 'unknown') as when the whole document is chardetted |
| 15:31 | <Philip`> | which gives http://philip.html5.org/data/chardet-lengths.txt |
| 15:31 | <Philip`> | for the first ~40K pages |
| 15:31 | <Philip`> | where the first unlabelled row is pages that weren't consistent at 64KB |
| 15:32 | <Philip`> | Oops |
| 15:33 | <Philip`> | Now updated, so it does include those with 'unknown' |
| 15:33 | <Philip`> | (About 80% of pages give 'unknown') |
| 15:36 | <Philip`> | (Gah, my output file is now a hundred megabytes of XML...) |
| 15:48 | Philip` | updates it again, to have all 130K pages and to maybe make more sense |
| 16:24 | <Lachy> | jgraham__, yt? |
| 16:25 | <jgraham__> | Yeah |
| 16:25 | <Lachy> | there seems to be a bug in html5lib |
| 16:25 | <Lachy> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3Cdiv%3E%3Ctable%3E%3Ca%3Ethe+following+whitespace+should+be+directly+in+the+div%3C%2Fa%3E+%3Ctbody%3E%3Ctr%3E%3Ctd%3Ebut+what+about+the+following+whitespace%3F%3C%2Ftd%3E+%3C%2Ftable%3E%3C%2Fdiv%3E |
| 16:25 | <Lachy> | according to the spec, the whitespace should not be added as a child of the table |
| 16:25 | <Lachy> | in that case |
| 16:26 | <jgraham__> | Was that one of the recent spec changes? |
| 16:26 | <Lachy> | I'm not sure, it's in this section http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tree-construction.html#parsing-main-intable |
| 16:27 | <Lachy> | since the table is tainted, the whitespace should be processed according to the anything else rules |
| 16:27 | <jgraham__> | Oh, if it involves the tainted stuff than it's a recent change |
| 16:27 | <Lachy> | ah, ok |
| 16:28 | <jgraham__> | Anne did some work on that but I don't know if he covered everything |
| 16:31 | <jgraham__> | Lachy: Of course it could just be that the parse tree viewer isn't up to date; did you check in a standalone copy? |
| 16:32 | <Philip`> | Could the parse tree viewer show which SVN revision it's running? |
| 16:32 | <Lachy> | no |
| 16:32 | <jgraham__> | Philip`: I'm sure it could somehow |
| 16:33 | <Lachy> | jgraham__, couldn't the viewer automatically update itself whenever there's a new version? |
| 16:34 | Philip` | accidentally commits 'system("rm -rf /");' into the html5lib repository |
| 16:34 | <jgraham__> | I guess I could use cron to try pulling from the source at regular intervals, but as Philip`so nicely points out it might not be a great idea |
| 16:35 | <jgraham__> | Philip`: Did you have a state transition diagram for the treebuilder somewhere? |
| 16:35 | jgraham__ | was wondering if we could check testcase coverage for all transitions |
| 16:36 | <jgraham__> | Lachy: I think the behaviour has changed now; I haven't checked if it is right or not yet |
| 16:36 | <Philip`> | jgraham__: http://philip.html5.org/misc/insertion-modes-3.svg |
| 16:37 | <Philip`> | (Also -2.svg and .svg - I can't remember what I changed) |
| 16:37 | <Philip`> | Maybe I can regenerate that for the new spec... |
| 16:38 | <jgraham__> | What do the colours mean? |
| 16:38 | <Philip`> | http://philip.html5.org/misc/insertion-modes-4.svg should match the current spec |
| 16:39 | <Philip`> | except for some quite likely errors |
| 16:40 | <Lachy> | it doesn't appear to be entirely correct, whitespace in within <tr> should be processed according to the rules for the in table mode, which would be the anything else section |
| 16:41 | <Philip`> | jgraham__: If a transition only happens after a parse error, then it's red; otherwise it's blue for reprocess-as-if, and black for set-insertion-mode |
| 16:41 | <Lachy> | it's currently putting it as a child of the tr, but, AIUI, it should be as a child of the div |
| 16:41 | <Lachy> | (in that above demo I linked to) |
| 16:41 | <jgraham__> | Lachy: That's the same conclusion I had reached |
| 16:41 | <Lachy> | ok |
| 16:41 | <jgraham__> | Philip`: Thanks |
| 16:41 | <Lachy> | jgraham__, see the PM i sent you |
| 16:42 | <jgraham__> | Lachy: Dunno if I can reply to PMs on freenode |
| 16:42 | <Lachy> | oh, isn't your nick registered? |
| 16:45 | <jgraham__> | No. I think technically someone else owns it which means I'm being really bad by using it but otoh, no one has ever complained |
| 16:46 | Philip` | avoids the name reuse problem by appending random significant punctuation |
| 16:47 | zcorpan | doesn't have that problem :) |
| 17:40 | <jgraham__> | Lachy: The whitespace thing should be fixed now |
| 17:41 | jgraham__ | has discovered a bunch of lxml-related breakage that needs to be fixed |
| 18:49 | <annevk> | whoa, @microsoft.com on @whatwg.org |
| 18:49 | <annevk> | oh wait, that was not a first |
| 18:50 | <a-ja> | anyone been doing any testing with betas regarding how figure/legend (or unknownelement/legend) works? |
| 18:51 | <annevk> | last i heard it didn't work wel |
| 18:51 | <annevk> | l |
| 18:51 | <a-ja> | gecko now is generating a fieldset :( |
| 18:53 | <a-ja> | whole doc after gets included in the fieldset....ouch! |
| 18:56 | <a-ja> | should there end up being a legend element in the DOM, or should it just generate a text child of figure? (sounded like the latter last i read the spec closely) |
| 18:57 | <annevk> | the former |
| 18:58 | <a-ja> | that makes more sense to me |
| 18:59 | <a-ja> | opera seems to do the latter? |
| 19:00 | <a-ja> | looked that way anyway....though i couldn't get the dev toolbar working for some reason...to view the dom |
| 19:00 | <annevk> | could be, we're not doing what HTML5 wants at this point |
| 19:01 | <annevk> | anyway, got to go |
| 19:01 | <a-ja> | take care |
| 19:39 | <Hixie> | there is some irony to the way that microsoft suggests xxx has a security problem when in fact xdr is the one increasing the attack surface |
| 19:46 | <Hixie> | Philip`: there's a line missing from InFrameset to AfterFrameset |
| 19:46 | <Hixie> | unless the spec itself is wrong somehow |
| 19:46 | <Hixie> | let me know if i'm being inconsistent or something |
| 19:47 | zcorpan_ | notes that #writing is not in sync with #parsing |
| 19:47 | <Philip`> | Hixie: Oops, that's because my spec-to-code regexp thing is incomplete and fails to understand that bit of text |
| 19:48 | <Philip`> | It's missing after-after-(body|frameset) -> in-\1 for the same reason |
| 19:48 | jwalden | is sad that <http://my.opera.com/desktopteam/blog/2008/03/18/happy-easter>; kinda-sorta-half-updated postMessage |
| 19:48 | <Hixie> | ah |
| 19:48 | <jwalden> | it's on window |
| 19:48 | <Hixie> | zcorpan_: oh? |
| 19:49 | <jwalden> | but it uses uri/domain |
| 19:49 | <Philip`> | Hixie: It would be much easier for me if you wrote the spec in OCaml instead of English |
| 19:49 | <jwalden> | Philip`: that's your objective opinion? |
| 19:49 | <jwalden> | ba-dum-ch |
| 19:50 | <Hixie> | Philip`: i believe you |
| 19:50 | <zcorpan_> | namely entities in escaping text spans (in rcdata) |
| 19:51 | <Hixie> | Philip`: i'm happy to make my text more self-consistent (i did a lot of changes to that effect recently so you should be able to simplify your regexps) but it's staying in english :-) |
| 19:53 | <zcorpan_> | i also found that #writing didn't say anything about the LF and <listing>, but then i remembered that <listing> is not valid in the first place :) |
| 19:54 | <zcorpan_> | but #serialising should talk about that |
| 19:56 | <zcorpan_> | speaking of serializing, i think the algorithm should change for (r)cdata elements to only emit the children text and cdata nodes |
| 19:56 | <zcorpan_> | s/ren// |
| 19:57 | <zcorpan_> | (including plaintext) |
| 19:58 | <zcorpan_> | less checking (hence better perf) and better roundtripping (comments are not turned into text but are instead just dropped) |
| 19:58 | <zcorpan_> | and it's what firefox does, i think |
| 20:00 | <Hixie> | zcorpan_: please send e-mail, i'm working on tables at the moment |
| 20:19 | <Hixie> | (othermaciej: is the windows safari 3.1 still labelled a beta?) |
| 20:19 | <othermaciej> | Hixie: no |
| 20:24 | <Hixie> | cool |
| 20:25 | <Hixie> | zcorpan_: the perf aspect is purely an implementation detail |
| 20:26 | <Hixie> | zcorpan_: how should the XML "<textarea><div> text</div></textarea>" be serialised by this algorithm? |
| 20:35 | <zcorpan_> | <textarea></textarea> |
| 20:37 | <a-ja> | for anyone interested in tracking: gecko figure/legend bug is 423721 |
| 20:38 | <zcorpan_> | (assming the elements are in the HTML namespace :) ) |
| 20:40 | <zcorpan_> | a-ja: doesn't <legend> only imply fieldset if it's foudn directly in body? |
| 20:41 | <zcorpan_> | a-ja: and is otherwise just dropped? |
| 20:41 | jwalden | wants <myth> |
| 20:43 | <a-ja> | zcorpan: well....i think it used to be that way....in body or unknown element...but since the post-b4 parser update to allow unknown (e.g. html5) elements to contains blocks, this has cropped up |
| 20:44 | <zcorpan_> | ah. haven't tested a build with the other fix in |
| 20:44 | <a-ja> | grab latest nitely if you wanna test....there was a related checkin yesterday |
| 20:45 | <Philip`> | Maybe someone should run the HTML5 parser tests in Firefox to try to find unintended consequences of that patch |
| 20:46 | <a-ja> | little late in beta cycle to replace ff's html parser with html5lib, i'd think :) |
| 20:47 | <a-ja> | sounds like a good idea though...since it hasn't made it to a beta release yet. though code freeze for "last" beta is tonite |
| 20:48 | <Philip`> | I'm not suggesting trying to make FF pass the tests - they're just a useful source of occasionally obscure HTML code that could be compared before/after the patch |
| 20:51 | <andersca> | Hixie: ping |
| 20:51 | <Hixie> | yo |
| 20:51 | <andersca> | hey |
| 20:51 | <a-ja> | pretty much, unknown elements can now have block children....instead of having to wrap them in an inline (e.g. span) to get em in DOM |
| 20:51 | <andersca> | Hixie: so I'm looking at the application cache spec |
| 20:53 | <Hixie> | i'm assuming you have a question related to this section? :-) |
| 20:54 | <andersca> | Hixie: actually, I have two! :) |
| 20:54 | <andersca> | Hixie: first, I didn't see an applicationCache property on the window interface |
| 20:54 | <Hixie> | yeah, known bug |
| 20:54 | <andersca> | OK |
| 20:55 | <andersca> | Hixie: and a small nit in 4.6.4, could p3 and p4 switch places? |
| 20:56 | <Hixie> | p3 and p4? |
| 20:56 | <andersca> | Hixie: step 3 and step 4 |
| 20:57 | <Hixie> | what difference does it make? |
| 20:58 | <Hixie> | step 3 doesn't have any visible side-effects |
| 20:58 | <andersca> | Hixie: none really, it's just that you don't need to define what the cache is until after step 4 |
| 20:58 | <andersca> | right |
| 20:58 | <Hixie> | i prefer to have all the definitions together |
| 20:58 | <Hixie> | makes it easier to find them |
| 20:58 | <Hixie> | blame my pascal upbringing :-) |
| 20:59 | <andersca> | OK, told you it was a small nit :) |
| 20:59 | <Hixie> | :-) |
| 21:01 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ca%20href%3Da%3Eaa%3Cmarquee%3Eaa%3Ca%20href%3Db%3Ebb%3C%2Fmarquee%3Eaa is different in FF3 vs FF2 |
| 21:17 | <othermaciej> | looks like every single news article about Safari 3.1 mentions HTML 5 |
| 21:18 | <jruderman> | what HTML 5 features does 3.1 have (over 3.0)? |
| 21:18 | <othermaciej> | the biggest are the video and audio elements and (nearly all of) their APIs |
| 21:19 | <othermaciej> | (also some smaller things like getElementsByClassName) |
| 21:21 | <othermaciej> | (of course, getElementsByClassName will probably get a lot more use in the near term) |
| 21:29 | <zcorpan_> | hmm... SSML? |
| 21:29 | <othermaciej> | what's SSML? |
| 21:30 | <zcorpan_> | http://www.w3.org/TR/speech-synthesis/ |
| 21:30 | <zcorpan_> | looks like a weird version of HTML to me |
| 21:33 | <andersca> | 3.1 also implements the Database spec |
| 21:40 | <othermaciej> | oh yeah |
| 21:44 | <virtuelv> | hehe, http://diveintomark.org/archives/2008/03/18/translation-from-ms-speak-to-english-of-selected-portions-of-joel-spolskys-martin-headsets |
| 21:47 | Philip` | wonders if he's intentionally misinterpreting "nobody has a way to test against the standard" as meaning testing browsers against standards, rather than testing web pages against standards |
| 21:50 | <zcorpan_> | hsivonen: when validating xhtml with resolving external entities, v.nu complains about shape attributes on <a>, even though the markup didn't have shape=''. i understand that the dtd resolves them, but it's probably confusing and unhelpful for authors... |
| 21:56 | <andersca> | Hixie: what happens if I setAttribute('manifest', ...) on the HTML element? |
| 21:56 | <Hixie> | nothing |
| 21:56 | <Hixie> | (as per the spec) |
| 21:56 | <Hixie> | the manifest attribute is only handled during parse time |
| 21:59 | <andersca> | great |
| 21:59 | <andersca> | :) |
| 21:59 | <andersca> | Hixie: oh, you are right - now why didn't I notice that |
| 22:00 | <Hixie> | search for "run the application cache selection algorithm" |
| 22:00 | <Hixie> | those are the only times that the attribute has any effect |
| 22:00 | <Hixie> | the spec defines the handling for XML files, text/plain files, and HTML files (in the HTML parser) |
| 22:01 | <Hixie> | oh and for images and plugins |
| 22:01 | <Hixie> | and error pages |
| 22:01 | <Hixie> | man, i was thorough |
| 22:02 | <andersca> | :) |
| 22:02 | <andersca> | that's good |
| 22:03 | <jgraham__> | Philip`: I'm not quite clear that Joel does mean "test web pages against standards", but he seems somewhat incoherent on that point |
| 22:04 | <Hixie> | i think joel doesn't understand that you can have pragmatic standards |
| 22:05 | <Hixie> | his argument seemed predicted on the concept of specs either being idealistic and unimplementable, draconian and unsuitable, or overly vague. |
| 22:05 | <Hixie> | he missed the "realistic and detailed" option |
| 22:05 | <othermaciej> | I'm not sure what his point was in his big rant |
| 22:05 | <othermaciej> | but I admit I didn't read the whole thing |
| 22:05 | <Hixie> | yeah me either |
| 22:05 | <Pavlov> | i started to read it but realized it kept going |
| 22:05 | <Hixie> | to not understanding the point |
| 22:05 | <Hixie> | (i did read it) |
| 22:06 | <jgraham__> | I think the point might have been to say he predicted in 2004 that Vista would suck |
| 22:07 | <Hixie> | his reasoning for why vista hasn't been the success that XP was seems somewhat flawed, imho |
| 22:10 | <Hixie> | jgraham__: do you have any discussion of the cell association algorithm anywhere? i'm curious to know which cases you were trying to solve |
| 22:10 | <Pavlov> | vista is in many ways nicer than XP |
| 22:10 | <Pavlov> | it just has some hickups |
| 22:10 | <jgraham__> | Hixie: I don't know if we have anything written down that's not in email |
| 22:11 | <Hixie> | i didn't see much discussion in the e-mails, mostly just algorithms :-) |
| 22:12 | <jgraham__> | Basically it's optimized for tables like http://annevankesteren.nl/2007/09/tmb-overview and http://sitesurgeon.co.uk/tables/tides/minimal.html |
| 22:14 | <jgraham__> | (which seems to be a fairly common general pattern) |
| 22:16 | <Hixie> | so a column (row) header's scope stops when it hits another header with the same width (height) and starting x (y) position? |
| 22:17 | <jgraham__> | Just the same with/height iirc although I guess maybe it should also consider the starting position |
| 22:18 | <Hixie> | i guess i'm going to have to just look at a lot of tables and determine the best algorithm that covers those tables |
| 22:18 | <Hixie> | yay for ben's work looking at tables |
| 22:19 | <Hixie> | k. bbiab. |
| 22:19 | <hallvors> | On Joel's article: http://my.opera.com/hallvors/blog/show.dml/1818385 |
| 22:19 | <jgraham__> | Hixie: Yeah. |
| 22:21 | jgraham__ | feels sorry for Hixie having to wade through all the crap in the table-related discussion |
| 23:03 | <Philip`> | Yay for search engine crawlers that DoS my server |
| 23:06 | <Philip`> | (I suppose I shouldn't provide an infinite number of URLs in a system that takes a large fraction of a second to generate each page with no caching or anything clever, but still they should be more considerate of bad server design...) |
| 23:25 | Philip` | wonders when Searchme will realise it's just getting Forbidden responses and stop requesting two pages a second |
| 23:37 | <hsivonen> | Philip`: thank you for chardet lengths. I think I'll probably run chardet on the first 512 bytes and running it on more than 1024 bytes doesn't appear to make much sense |
| 23:40 | <Philip`> | (Hmm, looks like Searchme uses pretty much the whole of 208.111.154.0/24, so I'll have to block all that...) |
