2011-12-01 [16:33:00.0000] rniwa: i just wish that if Japanese authors are going to dig in their heels and keep using SJIS (or EUC-JP or ISO-2022-JP), they'd at least get their charset declarations correct [16:33:01.0000] zewt: I think so. [16:34:00.0000] zewt: although Shift_JIS is never really used [16:34:01.0000] instead of the current nonsense where japanese pages very often end up broken on all non-japanese systems [16:34:02.0000] zewt: what we call Shift_JIS is almost always Code Page 932 [16:35:00.0000] windows's "extensions"--yet another reason to use utf-8 :P [16:36:00.0000] zewt: the problem is that utf-8 didn't get right either [16:36:01.0000] what's frustrating is how the current situation leads to pages working for their authors, and most of their viewers (eg. users in japan see japanese pages OK), but are broken for the rest of the world [16:36:02.0000] zewt: a lot of japanese/chinese scholars are really upset about how UCS-2 assignes the same code point for completely different characters [16:36:03.0000] zewt: right. [16:37:00.0000] zewt: on the other hand, it's pretty insulting to be imposed upon an encoding that can't encode your character properly [16:37:01.0000] eh, utf-8 round-trips other encodings, so i don't know how there could be anything sjis (etc) could represent that utf-8 can not [16:37:02.0000] zewt: how would you feel if your bank switched to start using utf-8 text encoding so that it starts using wrong characters for your names? [16:38:00.0000] i'm not convinced that's possible :) [16:39:00.0000] (with the caveat that you have to get your lang declarations right, to avoid rendering eg. japanese characters with chinese fonts) [16:39:01.0000] rniwa: Eh? UTF-8 got it wrong? You mean Unicode got it wrong? as another encoding for Unicode won't have different characters [16:40:00.0000] if there's any character in SJIS that doesn't have a direct round-trip equivalent in utf-8, that'd be a major unicode bug, afaik [16:40:01.0000] gavinc: I meant unicode [16:41:00.0000] if there's any character that isn't displayed identically in utf-8 (with the correct language selected) as in sjis, i'd be interested in knowing what it is, and why it's different [16:41:01.0000] so there exist japanese characters for which there is no unicode code point? [16:41:02.0000] Kanji yes? [16:41:03.0000] gavinc: well, they probably have all code points but the problem is that it's shared with chinese characters [16:41:04.0000] gavinc: yes [16:41:05.0000] zewt: even shift_jis doesn't contain all characters we need. [16:42:00.0000] rniwa: sharing with chinese characters is okay, again you just have to make sure the browser is picking the right language [16:42:01.0000] rniwa: Ah yes, the character is the same but two cultures define different meanings [16:42:02.0000] gavinc: it's the weird clash between "character" and "glyph" [16:42:03.0000] gavinc: they're different chracters [16:42:04.0000] gavinc: do you suppose greek alpha is identical to latin a because they share the same origin? [16:42:05.0000] rniwa: again, i'd like an example [16:43:00.0000] sorry, glyph [16:43:01.0000] meant glyph! [16:43:02.0000] anyways, i'm not in a position to discuss about this :) [16:43:03.0000] /me puts on encoding unicode brain [16:43:04.0000] rniwa: i think you're wrong :) [16:43:05.0000] there are much more qualified people to talk about it [16:43:06.0000] Yeah, pulling bits of it out my memory [16:43:07.0000] Greek has in fact some of the same political issues in unicode :( [16:44:00.0000] if you take sjis/euc-jp/iso-2022-jp text, convert to utf-8 and set lang=jp, it should always be rendered the same; if there are examples where this isn't the case, then I'd really like to know what they are [16:44:01.0000] Ah! Wikipedia will help you zewt http://en.wikipedia.org/wiki/Han_unification ;) [16:44:02.0000] gavinc: i know what han unification is; my point is that lang is the disambiguator [16:46:00.0000] zewt: http://www.shuiren.org/chuden/teach/code/main8.htm#AdvantageDisadvantage [16:48:00.0000] the problem with unicode is that they assigned characters with different shapes, lines, etc... to the same code point [16:48:01.0000] even though they're not just aesthetic issues [16:49:00.0000] e.g. you can't interchange them in handwriting because they're different characters [16:50:00.0000] rniwa: but the language attribute of the content tells it which glyph to use. [16:50:01.0000] zewt: that would mean that you can't mix chinese names and japanese names in the same context [16:50:02.0000] zewt: you have to specify the language to make any sense [16:51:00.0000] sure you can: text text2 [16:51:01.0000] and besides, you can't do that *at all* with legacy encodings [16:52:00.0000] http://zewt.org/~glenn/encoding%20utf-8.html http://zewt.org/~glenn/encoding%20sjis.html http://zewt.org/~glenn/encoding%20big5.html works fine [16:52:01.0000] (used zh-TW since the glyph difference is more pronounced) [16:52:02.0000] Could we define non-BMP characters that mirror all the BMP CJK glyphs but with the language predetermined? [16:52:03.0000] That would probably just confuse everyone even more . . . [16:53:00.0000] zewt: apparently chrome doesn't support it :( it looks all the same [16:53:01.0000] /me is annoyed [16:53:02.0000] Likewise. [16:53:03.0000] that'd be a massive chrome bug, unless I'm specifying something wrong [16:53:04.0000] (or both could be true) [16:54:00.0000] works fine in IE *8* [16:54:01.0000] zewt: firefox doesn't get it right either [16:54:02.0000] (and FF8, which I tested with first) [16:54:03.0000] is there an img reference too? [16:54:04.0000] zewt: this might be a bug on Mac... [16:54:05.0000] rniwa: you may not have both Japanese and Chinese fonts installed, in which case it'll probably fall back to the one you do have [16:54:06.0000] however, i can confirm it's not working for me in Chrome [16:55:00.0000] (windows, with both font sets installed) [16:55:01.0000] zewt: I have both Japanese / Chinese IMEs installed so that's hard to believe [16:55:02.0000] zewt: screen shot of what it -should- look like? [16:55:03.0000] one sec [16:55:04.0000] gavinc: the box inside the upper box should be on the different sides [16:56:00.0000] gavinc: see http://www.shuiren.org/chuden/teach/code/main8.htm#AdvantageDisadvantage [16:56:01.0000] http://zewt.org/~glenn/encoding%20expected.png [16:56:02.0000] gavinc: in JIS, it should be on the right. [16:56:03.0000] gavinc: in GB, it should be on the left. [16:56:04.0000] gavinc: in BIG5 it should be on the right but the bottom part should be simplified [16:57:00.0000] heh, so anyone else have the box in the top box on the LEFT? and not even on the right at all? [16:57:01.0000] gavinc: need traditional chinese font. [16:57:02.0000] gavinc: and I don't think zewt specified it to be traditional [16:57:03.0000] zewt: he probably used simplified chinese [16:58:00.0000] i used zh-TW, because it's easier to distinguish from the JP glyph [16:58:01.0000] zewt, gavinc: see, the problem is that it's so hard to use this thing. [16:58:02.0000] rniwa: oddly, I see the JP glyph on all three on the shuiren.org page [16:58:03.0000] zewt, gavinc: if we had a different code point, it just works fine. [16:58:04.0000] rniwa: yeah, I've been convinced. [16:58:05.0000] zewt: hehe, it's probably a browser bug [16:59:00.0000] I feel like this is a simialr issue to bidi [16:59:01.0000] rniwa: "see" but you're changing the argument :) these are browser issues (bad ones, to be sure; this should be working reliably years and years ago), but it's not unicode's fault [16:59:02.0000] it's possible in theory but impossible in practice [16:59:03.0000] uh, no, not at all [17:00:00.0000] zewt: the fact you're the only one seeing the correct glyph suggests to me that it's not working, is it? [17:00:01.0000] for authors there's exactly one step: stick lang=ja (or zh-TW or zh-CN) around your content (probably on ) [17:00:02.0000] zewt: but the problem is that it doesn't work in many cases. [17:00:03.0000] so it should be fixed; it's always worked for me [17:01:00.0000] zewt: what's the point of a spec. if it doesn't work on most implementations [17:01:01.0000] works fine in FF8 and IE [17:01:02.0000] On Windows [17:01:03.0000] zewt: maybe this is an issue with mac then [17:01:04.0000] FF8 does not look right on Linux [17:01:05.0000] and Opera [17:03:00.0000] hmm, Chrome does render the suiren.org page correctly [17:03:01.0000] zewt, gavinc: similarly, we have the opposite problem as pointed on http://www.shuiren.org/chuden/teach/code/main8.htm#AdvantageDisadvantage [17:03:02.0000] i bet that's because of the separate font specifier, though [17:03:03.0000] rniwa: executive summary would be helpful; it would take me several minutes to read this :) [17:03:04.0000] gavinc, zewt: 為 and 爲 are just new/old glyphs for the same character but they're assigned to different code points [17:04:00.0000] 骨 does look right on shuiren btw [17:04:01.0000] <- can struggle through gradeschool spoken JP, but reading it isn't going to happen [17:04:02.0000] I'll leave the rest to unicode experts from tokyo [17:04:03.0000] but i'm bitter about UCS-2 in general. [17:05:00.0000] chrome getting this wrong makes me upset; it's the sort of bug that'll set unicode-in-CJK-countries back by years [17:06:00.0000] zewt: yeah, I should probably file a bug about this. [17:06:01.0000] zewt: Chrome shows the WRONG thing for me on shuiren, where FF does the right thing [17:06:02.0000] it's super annoying [17:07:00.0000] rniwa: please do (I would, but I expect a webkit report will get more attention) [17:07:01.0000] also I wonder if this is a Chrome problem or a WebKit problem [17:07:02.0000] zewt: are you on windows? [17:07:03.0000] yeah [17:07:04.0000] zewt: because it works perfectly fine on mac. [17:07:05.0000] in chrome or safari? [17:07:06.0000] zewt: both [17:08:00.0000] zewt: it'll be super helpful if you could check safari as well [17:08:01.0000] will need to fire up my VM with safari in it; one sec [17:16:00.0000] eh, nothing is working right in my VM, not even the big5-encoded one [17:16:01.0000] they're all showing the JP glyph [17:16:02.0000] (XP, same on every browser I've tried) [17:16:03.0000] zewt: :( [17:17:00.0000] zewt: sounds like you don't have Eastern Asian language support on your Windows? [17:17:01.0000] it looks like XP installs all CJK languages as a unit ("install files for east asian languages"), so installed fonts should be a problem [17:17:02.0000] rniwa: if they weren't installed then the JP glyph wouldn't work either [17:17:03.0000] zewt: oh they all defaults to JP font? [17:18:00.0000] yeah, even big5 shows the top one in http://zewt.org/~glenn/encoding%20expected.png [17:18:01.0000] the fonts are there; i can see one of the ZH ones if I select the NSimSun font in Notepad [17:19:00.0000] i guess i'll install safari natively instead of in this old XP VM [17:19:01.0000] strange, though [17:20:00.0000] (and so nobody's confused, this is unrelated--the problem happens with the legacy encodings, too) [17:21:00.0000] this is fascinating: the Safari installer gave me the option to not auto-updated in XP, but that option seems to be mysteriously not present in 7 [17:22:00.0000] WHAT THE HELL [17:22:01.0000] okay safari is on my software blacklist (it just played loud music when it launched) [17:23:00.0000] that is not okay [17:25:00.0000] rniwa: safari is showing the JP glyph in all cases, as far as I can see [17:26:00.0000] including big5 [17:26:01.0000] zewt: okay, it's probably webkit issue then [17:26:02.0000] rniwa: does big5 look wrong to you, too? [17:27:00.0000] that is, http://zewt.org/~glenn/encoding%20big5.html, which shows the zh-TW glyph for me [17:27:01.0000] (in FF) [17:34:00.0000] zewt: it doesn't properly on mac either [17:34:01.0000] odd. it appears to use simplified font on windows :( [17:35:00.0000] looks to use MS Gothic always for me [17:35:01.0000] zewt: filed https://bugs.webkit.org/show_bug.cgi?id=73507 [17:37:00.0000] rniwa: fwiw, you can probably remove the lang attribute there [17:37:01.0000] since it seems to happen without it [17:39:00.0000] zewt: http://www.shuiren.org/chuden/teach/code/main8.htm renders correctly on Chrome on Windows for me [17:40:00.0000] rniwa: it seems to have some xhtml-related problem for me [17:40:01.0000] if I s/xml:lang/lang/, it works [17:41:00.0000] er, no, that was in FF [17:41:01.0000] (overjuggling) [17:42:00.0000] zewt: ? [17:42:01.0000] (it renders wrong in FF8 for me, because of something to do with xhtml) [17:43:00.0000] rniwa: it renders correctly in Chrome only because of the font-family style [17:43:01.0000] œ [17:43:02.0000] :( [17:43:03.0000] it's not actually using the language there [17:43:04.0000] that's quite stupid [17:44:00.0000] so i'm guessing it shares whatever safari's problem is with lang [17:47:00.0000] rniwa: do you at least agree that, if browsers iron this stuff out (which should have happened long ago), language tagging + UTF-8 is a workable approach for authors to deal with han unification? [17:47:01.0000] (that is, all you do is add lang=jp to ) [17:47:02.0000] (for the vast majority of cases) [17:48:00.0000] zewt: not really. I still think it's broken in many ways. but I'd agree that we should fix it. [17:48:01.0000] why? [17:48:02.0000] zewt: so that we can at least get the functionality UCS-2 provides. [17:48:03.0000] zewt: I've already pointed out the code point issues. [17:49:00.0000] which language tagging fixes (and that's how CJK unicode rendering was intended to work from the beginning) [17:50:00.0000] zewt: not really [17:50:01.0000] ... [17:50:02.0000] zewt: some characters are assinged to two different code points even though they're the same character [17:50:03.0000] of different styles [17:50:04.0000] so? [17:50:05.0000] zewt: that would mean that changing fonts don't work [17:50:06.0000] zewt: you need to edit the html to use different styles of characters [17:50:07.0000] etc... [17:51:00.0000] there are multiple codepoints for "A" (full-width latin); it's a little weird but not a real problem [17:53:00.0000] (when I see it I wish people wouldn't use it, but it's not nearly annoying enough to not use UTF-8 for) [18:18:00.0000] I assume you guys know about UVS [18:22:00.0000] (not off-hand) [18:24:00.0000] a Unicode feature that uses supplemental codepoints to encode glyph variations [18:25:00.0000] I believe it's partly intended to address the complaints about Han unification [18:26:00.0000] language markup works too, although it's confusing because language often affects font choice as well as shaping [18:26:01.0000] well, shaping is just part of the font in most systems [18:26:02.0000] E.g. your language attributes might fix the problem by causing a suitable font to be selected [18:27:00.0000] but if you explicitly set the "wrong" font (or the user does, maybe), you'd lose [18:27:01.0000] japanese fonts generally don't have chinese glyphs in them to begin with (putting aside that ttf fonts probably have no way to express that; don't know) [18:28:00.0000] right, so if someone forced use of a Japanese font, then your Chinese text won't display properly [18:28:01.0000] Opentype fonts can use language-specific shaping tables, and Gecko supports that, but I don't know how many fonts do [18:28:02.0000] that could be fixed in time, of course, though i suspect mixing japanese and chinese glyphs is too much of an edge case for the cost [18:28:03.0000] so a font could support both Japanese and Chinese correctly [18:30:00.0000] but this isn't actually a problem with the lang markup approach (eg. I doubt encoding it with Unicode features would change it) [18:30:01.0000] it's just limitations of the fonts and font engines [18:31:00.0000] true [18:59:00.0000] wg what? [19:02:00.0000] wow thg [19:02:01.0000] /me fails at anagrams [20:02:00.0000] roc, you mean IVS? (Ideographic Variation Sequences) [20:13:00.0000] yes [22:59:00.0000] where do I see the system requirements for Opera Next? [23:44:00.0000] categorizing elliptical arcs and elliptical curves as graphics or crypto could be a CAPTCHA question [23:52:00.0000] hsivonen: the same as http://www.opera.com/browser/download/requirements/ prolly [23:52:01.0000] hsivonen: not sure if we have that stated somewhere [23:57:00.0000] I don't get the XPath thread, why don't the proponents simply write a spec and get it implemented? [23:57:01.0000] so there's discussion about incremental XHR, but no discussion about incremental HTML/XML parsing APIs [23:58:00.0000] Is that even needed though? [00:00:00.0000] whatwg.org slow? [00:01:00.0000] consider a page that inserts new content fetched from xhr [00:01:01.0000] currently people wait for everything to download, and then assign innerHTML or so [00:02:00.0000] with chunked XHR, they still need to wait for everything before assigning to innerHTML [00:02:01.0000] so some new kind of document.write() API? [00:03:00.0000] yeah [00:03:01.0000] o_O [00:03:02.0000] element.write() :) [00:07:00.0000] annevk: ok. Re: requirements [00:08:00.0000] annevk: Re: XPath: it's not just an issue of the proponents getting it implemented. patches might not be welcome if they are perceived as a slippery slope to having to get on the XPath 2 maintenance treadmill [00:09:00.0000] annevk: IIRC, some WebKit/Qt hacker tried to contrib XPath 2 (or was it XSLT 2) support, but the wider WebKit stakeholders wisely rejected it [00:09:01.0000] Okay, but e.g. EXSLT has been implemented by some browsers... [00:09:02.0000] From what I remember anyway, it's been a while [00:10:00.0000] annevk: yeah, at the time when Mozilla accepted patches for pretty much anything than looked stardardish [00:12:00.0000] fortunately for math, MathML got in the codebase, too, during that era [00:22:00.0000] hsivonen: I asked and our system requirements are so low that nobody has really cared to put that amount of detail into experimental releases [00:22:01.0000] hsivonen: runs on => W2K and we only just ditched W9x support if that means anything to you [00:22:02.0000] /me has a fast Mac, doesn't care [00:26:00.0000] 3PM ET == 9PM CET? [00:26:01.0000] MikeSmith, ^^ [00:26:02.0000] /me might not make that [00:27:00.0000] annevk: no problem [00:27:01.0000] that was the only time it seems we could get everybody on [00:27:02.0000] yeah, have fun :) [00:27:03.0000] well, not everybody, obviously [00:27:04.0000] I honestly don't know what's left to say about that, anyway [00:28:00.0000] I thought my last message in the thread made it all pretty clear [00:28:01.0000] some people like to talk to talk [00:28:02.0000] or something [00:28:03.0000] yeah [00:28:04.0000] for three years [00:28:05.0000] saying the same things without actually doing much of anything concrete [00:29:00.0000] anyway, I need to step out for food and drink [00:30:00.0000] long evening of late-night telcons to look forward to [00:31:00.0000] go to the fancy sushi place :) [00:33:00.0000] annevk: Yeah, someone should write a spec for teh XPath thing. I can't really do it though as either bratell or Katie would kill me. Maybe João should do it. [00:37:00.0000] zcorpan: fwiw, until queue a task moves to DOM4, it's the wrong place to spec APIs around it imo [00:38:00.0000] jgraham: you should write notifications already :p [00:38:01.0000] annevk: I know :) [00:38:02.0000] jgraham: why would Katie kill you though? you'd do it in your free time? [00:38:03.0000] jgraham: didn't realize the Xpath-love was so strong with you :p [00:39:00.0000] Well yeah, the two options would be use work time -> death by bratell, use free time -> death by Katie. Both options end in death. I don't like XPath *that* much [00:39:01.0000] it would be nice though if there finally was a spec that said how //text() works with DOM-based environments [00:40:00.0000] annevk: moved the bug [00:41:00.0000] thanks [00:41:01.0000] jgraham: what happens if you use half the time on work time and the other half on free time? [00:42:00.0000] coma [00:43:00.0000] Isn't that how you unleash the special 2 v 1 mode that leads to quick, but painful, death? [00:43:01.0000] *unlock [00:44:00.0000] Anyway, seriously, not going to happen at the moment [00:49:00.0000] annevk: so about setAttributeNS / setAttribute difference, [00:49:01.0000] annevk: the problem is that setAttributeNS does more than just setting the value [00:49:02.0000] annevk: it also modifies the namespace prefix [00:50:00.0000] annevk: so I'd have to special-case that :( [00:50:01.0000] modifying prefix seems annoying [00:51:00.0000] rniwa: ideally we remove that [00:51:01.0000] rniwa: it currently does not do that in WebKit or Opera [00:51:02.0000] rniwa: Gecko does do it, but then mutation observers does not take it into account [00:51:03.0000] annevk: how about IE? [00:52:00.0000] I cannot test IE :( [00:52:01.0000] i didn't even know about namespace prefix stuff 'til I read the spec [00:52:02.0000] it's super annoying [00:52:03.0000] if you paste http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0214.html in the live dom viewer you can find out what IE does [00:52:04.0000] /me boots his windows machine [00:52:05.0000] rniwa: say so in the www-dom thread! [00:53:00.0000] rniwa: if everyone but sicking finds it annoying, we're just going to not do it [00:53:01.0000] as it's a super edge case not worth caring much about [00:53:02.0000] annevk: i'm waiting 'til my spec goes on public-webapps [00:54:00.0000] I highly doubt that any author understands this behavior [00:54:01.0000] but then.. very few people use setAttributeNS anyway [00:54:02.0000] annevk: finds what annoying? [00:54:03.0000] so maybe those people get annoyed ? [00:54:04.0000] annevk: i find prefixes annoying in all forms :) [00:54:05.0000] sicking: setAttributeNS doing more than setting the value [00:54:06.0000] node prefixes that is [00:54:07.0000] sicking: namespace prefix changes in setAttributeNS [00:55:00.0000] annevk: oh, I don't believe I said anything on that topic at all [00:55:01.0000] sicking: it makes undo manager / DOM4 spec more complicated :( [00:55:02.0000] annevk: other than that i'd like to get rid of namespaced attributes [00:55:03.0000] am I confusing sicking and bz again [00:55:04.0000] :( [00:55:05.0000] sorry sicking [00:55:06.0000] annevk: bz has a much nicer beard than me [00:56:00.0000] heh, I'd love to meet him one day [00:56:01.0000] i thought you met him in MV once [00:56:02.0000] but maybe you weren't there [00:56:03.0000] ooh maybe a long time ago [00:57:00.0000] annevk: as I've suspected, IE supports it [00:57:01.0000] annevk: live DOM viewer shows e:a="b" [00:57:02.0000] kk [00:59:00.0000] I think http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0222.html is a very compelling argument though and therefore I think I will just remove it [00:59:01.0000] and I'll file a bug on Gecko to see if they are willing to match the spec [01:02:00.0000] alright [01:02:01.0000] my spec just got real :D [01:02:02.0000] all pending issues have been resolved [01:03:00.0000] you mean the first 80%? [01:03:01.0000] the remaining 80% takes half a decade :p [01:03:02.0000] annevk: basically, I don't have anything to add at this point except clarifying details (which is going to take another 2 years to finish) [01:03:03.0000] annevk: yeah, the first 80%. [01:03:04.0000] annevk: the remaining 20% will take 2 years + 10 years for writing tests [01:04:00.0000] well at least in my optimistic estimate [01:04:01.0000] congratulations though, still pretty sweet :) [01:04:02.0000] annevk: yeah, i'm super excited about it [01:04:03.0000] /me needs to update the date and push it to rniwa.com [01:05:00.0000] You probably also need to get implementations ;) [01:05:01.0000] jgraham: yeah... [01:05:02.0000] jgraham: I was hoping to get an intern do it [01:05:03.0000] jgraham: but apparently people want it before next summer [01:06:00.0000] so i guess i'll do it in Q1 [01:08:00.0000] jgraham: I hear sicking had an intern start implementing it for gecko [01:08:01.0000] rniwa: yeah, he got far but didn't finish it. Don't know when we'll be able to do the remaining parts :( [01:09:00.0000] sicking: sounds like he has a full-time offer? [01:09:01.0000] rniwa: oh, there's one part that i notcied that you're missing [01:09:02.0000] sicking: ? [01:09:03.0000] rniwa: you only have info on how to revert changes [01:09:04.0000] rniwa: not how to reapply them [01:09:05.0000] sicking: right [01:09:06.0000] sicking: oh, so reapply will be reverts of reverts [01:10:00.0000] rniwa: hmm... is that always true [01:10:01.0000] sicking: I think so. [01:10:02.0000] could be [01:11:00.0000] sicking: if there are cases where that's not the case, then let me know [01:11:01.0000] sicking: but I haven't been able to come up with a case yet. [01:11:02.0000] still needs to be defined. But if it's that simple i might have missed it. [01:11:03.0000] sicking: so in http://rniwa.com/editing/undomanager.html#automatic-dom-transactions [01:12:00.0000] sicking: I say "When an automatic DOM transaction is reapplied, the user agent must revert DOM changes made inside the undo scope of the the UndoManager while unapplying the transation." [01:12:01.0000] sicking: whereas for unapply, I said "When an automatic DOM transaction is unapplied, the user agent must revert DOM changes made inside the undo scope of the the UndoManager while *applying* the transation" [01:15:00.0000] What's the best workflow for going from .ttf to a subsetted .woff these days in a way that doesn't break ligatures and contextual alternative glyphs? [01:15:01.0000] is it Philip`'s subsetter plus a separate .ttf to .woff converter? [01:15:02.0000] sicking: does that make sense? or should I clarify more? [01:19:00.0000] rniwa: that means that the implementation must continuously update it's automatic transaction though, is that good? [01:19:01.0000] rniwa: currently in gecko we just store information when the transaction is created, and that information remains constant as we apply/unapply [01:20:00.0000] !? [01:20:01.0000] sicking: right. [01:21:00.0000] sicking: I don't really follow your continuously updating part. [01:21:01.0000] rniwa: say that you create an automatic transaction which inserts a node [01:21:02.0000] sicking: I'm not saying that you should implement each mutation inside undo/redo as an automatic transaction [01:22:00.0000] rniwa: a transaction-object is created which stores a reference to that node (and maybe other information) [01:22:01.0000] rniwa: say that the page the removes the node from the DOM [01:22:02.0000] rniwa: and then calls unapply [01:22:03.0000] rniwa: at this point unapply can't remove the node since it no longer has a parent [01:22:04.0000] sicking: right [01:22:05.0000] rniwa: in other words, unapply doesn't do anything [01:22:06.0000] sicking: sure. [01:23:00.0000] sicking: so it didn't make any DOM changes [01:23:01.0000] sicking: if you do reapply at that point, reapply doesn't do anything [01:23:02.0000] rniwa: per spec, that means that the transaction has to update it's internal information to now represent nothing [01:23:03.0000] hm.... [01:23:04.0000] sicking: would that be an issue? [01:23:05.0000] rniwa: in other words, the transaction doesn't hold constant data [01:23:06.0000] rniwa: seems harder implementation wise. To no benefit as far as i can see [01:23:07.0000] Philip`: do you happen to know of an up-to-date .ttf to .woff converter that runs on Linux? [01:24:00.0000] hm... [01:24:01.0000] rniwa: in fact, it's probably good if the implementation holds the data so that it can try to re-insert the node if you reapply [01:24:02.0000] sicking: ok, I think you're right. [01:24:03.0000] sicking: i guess I'll just change the spec then [01:25:00.0000] rniwa: thanks. I do think that'll make implementation a good bit simpler [01:25:01.0000] hsivonen: is fontsquirrel broken? [01:27:00.0000] zcorpan: do you mean this: http://www.fontsquirrel.com/fontface/generator [01:27:01.0000] zcorpan: it's not something I can automate on Linux [01:27:02.0000] zcorpan: is that the best that's available? [01:27:03.0000] no idea [01:27:04.0000] (Flash-based file upload. boo.) [01:28:00.0000] ugh [01:31:00.0000] sicking: yeah, I guess I wasn't thinking through [01:31:01.0000] /me replies some random email about Arabizi [01:32:00.0000] I don't quite understand what they're trying to propose though [01:34:00.0000] should the DOM specification have these kind of anal definitions: [01:35:00.0000] X attribute: An attribute whose local name is X and namespace and namespace prefix are null [01:35:01.0000] has an X attribute: An element that has an X attribute in its attribute list [01:36:00.0000] s/has an X attribute/has an attribute/ [01:39:00.0000] I'm just going to go with it [01:39:01.0000] someone can tell me otherwise later [01:41:00.0000] annevk: that sounds fine [01:41:01.0000] annevk: although "has an X attribute: An element that has an X attribute in its attribute list" sounds like a recursive definition [01:48:00.0000] sicking: I suppose there's no sanity check required for reapplying DOM changes? [01:49:00.0000] hm... i guess there's some. [01:49:01.0000] if you just say element has an attribute, where do you look? [01:49:02.0000] it's commonly assumed you look in its attribute list and in fact it's the only logical thing to do [01:49:03.0000] but it's not written down [01:49:04.0000] annevk: right. [01:49:05.0000] at least not so far [01:50:00.0000] :) [01:50:01.0000] annevk: I'd say that an element E has an attribute A if an attribute A is in E's attribute list. [01:51:00.0000] annevk: we should really kill attribute nodes [01:51:01.0000] yeah, that's the definition [01:51:02.0000] rniwa: already done spec-wise... [01:51:03.0000] annevk: oh really? [01:51:04.0000] hm... we just need to kill the ones in the wild i guess? [01:51:05.0000] rniwa: Gecko is trying that for us [01:52:00.0000] annevk: great! [01:52:01.0000] rniwa: they give plenty of warnings if you try to do Attr node related stuff [01:52:02.0000] annevk: I think we can improve the DOM perf. a lot once we get rid of attr nodes [01:52:03.0000] made Facebook stop using it [01:52:04.0000] annevk: that's very nice [01:53:00.0000] attribute nodes are DTD legacy :( [01:54:00.0000] so in a way we can blame Dan Connolly for convincing Tim HTML had to be SGML-based [01:54:01.0000] (rather than just inspired, as HTML 1 was) [02:03:00.0000] annevk: really? I didn't know that history, that's very interesting [02:10:00.0000] sicking: e.g. in http://www.w3.org/People/Raggett/book4/ch02.html search for "July 1994" [02:11:00.0000] sicking: or http://infomesh.net/html/history/early/ [02:12:00.0000] Dan told me in person, too :) [03:10:00.0000] I've got a weird problem with firefox recently: almost everywhere I click appears a blinking vertical text bar. Wut? [03:11:00.0000] Press F7 [03:12:00.0000] Wow, thanks. [03:12:01.0000] What's that option anyway? [03:12:02.0000] Found it, nvm. [03:13:00.0000] It's caret browsing mode; supposed to help keyboard navigate web pages iirc [03:14:00.0000] "Allow text to be selected with the keyboard" [03:22:00.0000] looking for a place to ask simple questions related to html5 etc. Like "is header img {}" acceptable? [03:23:00.0000] here might work. or #html5 [03:26:00.0000] Cheers - I suppose my question is does
respond to normal block level css - so I could center a log iusing margin, etc? [03:26:01.0000] logo* [03:27:00.0000] Generally HTML elements are entirely independent of CSS [03:27:01.0000] In the sense that any CSS rule can be applied to any element [03:27:02.0000] The only exception is replaced content including forms [03:29:00.0000] thanks jgraham - it is probably just me having difficulty centering a logo in a header. [03:49:00.0000] hsivonen: I know almost precisely nothing about WOFF [04:13:00.0000] opalepatrick: in browsers that don't support
, it's an inline element, so you need to set it to display:block to work as you expect [04:38:00.0000] thanks very much for that zcorpan - worked perfectly - I am surprised that firefox 8 doesnt actually support header like that [04:46:00.0000] I find it a bit unintuitive that overflow: -o-paged-x; is declared inside an @media -o-paged {} at-rule [04:46:01.0000] so the media is somehow considered paged before paging is enabled [04:47:00.0000] iirc annevk suggested the at-rule could be dropped [04:52:00.0000] also, -o-paged-x-controls is uglyish and doesn't work nicely when set on an element that has rounded corners. [04:52:01.0000] furthermore, on Linux, height: 100% on the root means 100% of the screen height [04:52:02.0000] which makes no sense when the browser chrome takes part of the screen height [04:53:00.0000] so I get both paging and a vertical scrollbar [04:53:01.0000] Sounds like a bug [04:53:02.0000] sure [04:55:00.0000] in other news, having three consecutive elements two first ones of which have page-break-after:avoid; allows a page break between the first and the second instead of moving all three to the next page [05:04:00.0000] so I have a floating image with a negative margin right. When it's on a column on the left, it gets clipped by the column to the right [05:05:00.0000] Opera Reader bug or a CSS multicol feature? [05:05:01.0000] do I need some z-index trick to make an image that pokes out of its column paint on top of the next column? [05:16:00.0000] looks like break-inside: avoid-column; is not supported :-( [05:20:00.0000] even more curious than the Linux case of height: 100% referring to screen height, on Honeycomb, it also refers to the screen height instead of the height left to the app after the system has taken the actionbar space [05:21:00.0000] hsivonen: If you file [a|some] bug[s], can you point me at [it|them] and I will try to make sure they reach the right people [05:26:00.0000] Oh, mailman day again [06:30:00.0000] /me notices that transfer of .nu domain name from loopia costs 2,387.50 SEK [06:30:01.0000] .mobi is free to transfer [06:51:00.0000] heh [06:51:01.0000] telnet miku.acm.uiuc.edu [06:55:00.0000] /me has never used telnet [06:55:01.0000] Things that are weird: In Dave Raggett's book he talks about himself in the third person [07:08:00.0000] Hello [07:11:00.0000] maybe someone has experience with Video conferencing and peer-to-peer communication ? [07:13:00.0000] StewieG, if you have a question, best to just ask it. [07:13:01.0000] Then hang around and wait. [07:13:02.0000] Someone might get back to you after a while. [07:14:00.0000] There are definitely people here who are familiar with those parts of HTML, yes. [07:32:00.0000] AryehGregor: Not good enough it seems [07:33:00.0000] What's not good enough? [07:41:00.0000] I did live video streaming from a "conference" early this morning using html5 et al. :-) [07:45:00.0000] Hixie: How do I upload files to the whatwg wiki? I've got some screenshots for the text-input-mode page. [07:53:00.0000] AryehGregor: Ask a question and wait [08:23:00.0000] seem to recall having a discussion about callback-based blobs for providing data sources, but can't remember where... [08:24:00.0000] found it, "File API Streaming Blobs" [08:57:00.0000] hi [09:00:00.0000] Philip`: the code you suggested yesteday to emulate the useful "copy" is not working because the "crop" does not consider the width of a single line as a path [09:04:00.0000] anyone here? [09:06:00.0000] Is it possible to change the spec about "copy" of globalCompositeOperation in canvas to make it like the current chrome implementation or to add a new globalCompositeOperation to have the same result? [09:06:01.0000] nick5437, you might want to file a spec bug. [09:06:02.0000] Noting how all the different browsers behave would be useful. [09:07:00.0000] If other major browsers also behave that way, then you could probably make a good case for it. [09:08:00.0000] firefox used to do the "copy" in that way too but they changed idea only to be with spec, not because the spec "copy" is useful in real uses. there is an interesting conversation in the bug fix about that in firefox [09:08:01.0000] nick5437: The compositing behaviour has been discussed several times, about making it only apply to pixels that are drawn and not to any outside the shapes, but it seems unlikely to change unless someone can at least define precisely how to determine what pixels are drawn (in a way that can be interoperably implemented) [09:09:00.0000] (including interaction with shadows etc) [09:13:00.0000] is it possible to add a new globalCompositeOperation that do the same? browsers like firefox already have the code to do both "copy" so it could become real in a realistic time, right? [09:14:00.0000] i think the old firefox copy and current chrome [09:14:01.0000] It's only possible if someone can define precisely how it should work :-) [09:14:02.0000] /me doesn't know how well the old implementations matched each other [09:17:00.0000] is it ok for the spec an image with about 5 examples about the way it should work with shadows and opacity? A picture is worth a thousand words sometimes. to avoid browser confusion on implementation like now [09:18:00.0000] nick5437, I'm pretty sure a precise definition is needed, not just examples. [09:18:01.0000] Pictures are too ambiguous to specify behaviour, though they can be very useful when trying to figure out what behaviour to write down [09:19:00.0000] the actual specs using text only have generated lots of confusion in my opinion [09:19:01.0000] http://www.rekim.com/2011/02/11/html5-canvas-globalcompositeoperation-browser-handling/ [09:20:00.0000] or the browser creators are not able to read the specs [09:21:00.0000] I believe all implementors agree on the understanding of what the spec specifies [09:21:01.0000] what's the service that runs under the username lhunt on whatwg.org? [09:21:02.0000] the blog? [09:21:03.0000] (though they haven't all got around to implementing it that way) [09:22:00.0000] looks like it's the blog, the forum is under whatforum and the wiki under whatwiki [09:22:01.0000] assuming it's the blog, the blog is getting hit hard at the moment, wtf [09:29:00.0000] My english is not so good to create a detailed spec (I'm not a native). Could I post an image with examples about the "goodcopy" and let others on the review process to formulate a good text spec? [09:34:00.0000] nick5437, writing good specs is very hard. It's not just about phrasing it, it's about figuring out all the corner cases. [09:34:01.0000] In this case, good performance might be essential too. [09:36:00.0000] the code of what I'm proposing is already there on firefox and chrome. I'm just proposing to call "goodcopy" the actual chrome implementation of "copy" and "copy" the actual implementation of "copy" on firefox [09:36:01.0000] Are you assuming they're actually interoperable in corner cases? [09:41:00.0000] i tried it with different opacities and the implementation looks fine. The whole stuff I'm talking about creating lines with different opacities, size and blur in drawing apps using tablet pressure [09:43:00.0000] Hixie, I'm iterating on the change proposals for time/data to include responses to issues/alternatives raised and I wanted to get your opinion on a few things [09:44:00.0000] I think tablet pressure + html5 is something interesting and the "goodcopy" an easy way to use it without changing all the line specs or adding a new line type [09:59:00.0000] Hixie, in particular, for