| 00:00 | <TabAtkins> | Yay, done. http://code.google.com/p/chromium/issues/detail?id=67629 |
| 00:04 | <jamesr_> | prz to file in bugs.webkit.org kthxbai |
| 00:07 | <TabAtkins> | Goddammit. |
| 00:07 | <Hixie> | hah |
| 00:11 | <TabAtkins> | jamesr_: https://bugs.webkit.org/show_bug.cgi?id=51362 |
| 00:13 | <boblet> | member:Hixie: when using <time datetime=""> is it ok to use a datetime without a timezone (floating time), or is a timezone (or Z) required? |
| 00:13 | Hixie | looks |
| 00:14 | <Hixie> | boblet: does the element have a pubdate attribute? |
| 00:14 | <Hixie> | (not that i think it matters in this case) |
| 00:14 | <Hixie> | (but it'll simplify my answer) |
| 00:14 | <boblet> | possibly :) this was an enquiry on html5doctor |
| 00:15 | <Hixie> | hm actually it does matter |
| 00:15 | <boblet> | spec says requires “valid date string with optional time” which to me would make timezone optional, but links to 2.5.5.7 (timezone required) |
| 00:15 | <Hixie> | why would "valid date string with optional time" mean the timezone was optional? |
| 00:16 | <Hixie> | a valid date string with optional time is a string that is either a valid date string, or a valid global date and time string |
| 00:17 | <Hixie> | i.e. it's the time that's optional, not the time zone |
| 00:17 | <boblet> | hixie: aah ok. I initially read it as any of the datetime microsyntaxes would be ok |
| 00:17 | <boblet> | but the link indicated I was wrong |
| 00:17 | <Hixie> | no, only the ones it says are ok are ok :-) |
| 00:18 | <Hixie> | that's why it says which one is ok :-) |
| 00:18 | <boblet> | hehehe |
| 00:18 | <hober> | so, for instance, it can be 2010-12-20, or 2010-12-20T16:24:00-08:00 |
| 00:19 | <boblet> | does that include non-pubdate uses of <time>? |
| 00:19 | <Hixie> | to answer your original question, the answer is "it depends" -- if it has a pubdate attribute, then datetime must be a date or a date+time+timezone; if it has no pubdate attribute, then datetime must be either a date, or a time, or a date+time+timezone. |
| 00:19 | <Hixie> | this is all defined here: http://www.whatwg.org/specs/web-apps/current-work/#attr-time-datetime |
| 00:19 | <boblet> | oh! so when would a non-timezone datetime (local datetime) be used? |
| 00:20 | <Hixie> | <p>I usually have a snack at <time>16:00</time>.</p> |
| 00:21 | <boblet> | 2.5.5.4 Local dates and times specs a date + time with no timezone |
| 00:21 | <Hixie> | (so you can style it to be "I usually have a snack at 4pm.") |
| 00:22 | <Hixie> | yes |
| 00:22 | <boblet> | is it possible to use 2.5.5.4-style datetimes with <time>? |
| 00:23 | <hober> | <p>I had a snack <time datetime="2010-12-20T16:00:00">this afternoon</time>.</p> |
| 00:24 | <hober> | not sure if that's OK per spec |
| 00:24 | <Hixie> | boblet: not currently, no |
| 00:24 | <boblet> | hober: that conflicts with what Hixie wrote above (“ if it has no pubdate attribute, then datetime must be either a date, or a time, or a date+time+timezone.”) |
| 00:24 | <hober> | boblet: yeah |
| 00:24 | <Hixie> | the spec seems pretty clear cut on all this to me :-) |
| 00:24 | <boblet> | Hixie: ok thanks. Appreciate you clearing that up |
| 00:24 | <Hixie> | what is it about the spec that makes this confusing? |
| 00:24 | <Hixie> | i really should make the spec clearer if all this can't be determined straight from following th elinks in the spec |
| 00:25 | <boblet> | yeah, I didn’t write the article, so I don’t know if it was a misreading or if the spec changed to make local datetimes invalid for @datetime |
| 00:25 | <boblet> | could also be that microformat datetimes are generally local (no-timezone) oners |
| 00:26 | <boblet> | will update our article |
| 00:28 | <hober> | I don't think that assertion makes sense re: microformat datetimes |
| 00:28 | <hober> | Most hAtom I've seen in the wild uses Atom-like RFC3339 productions, including tz |
| 00:30 | <TabAtkins> | I know that I just use date('c') for my stuff, which produces a tz. |
| 00:31 | <TabAtkins> | (From PHP.) |
| 00:31 | <Hixie> | there aren't really that many use cases for timezone-less datetimes in output, from what i can tell |
| 00:32 | <Hixie> | but it's not clear that <time> has enough use cases to really justify it anyway |
| 00:32 | <Hixie> | and it might end up being dropped |
| 00:32 | <TabAtkins> | "The ball starts to drop at <time datetime=2010-12-31T23:59:50>10 seconds before midnight!</time>." |
| 00:32 | <Hixie> | that's not really right |
| 00:33 | <Hixie> | it's 10 seconds before midnight EST :-) |
| 00:33 | <TabAtkins> | I think <time> is useful enough just for being a carrier of datetime information for microformats/microdata. |
| 00:33 | <TabAtkins> | All of the balls drop at the same local time. |
| 00:33 | <boblet> | hober: any hand-authored hEvent probably won’t contain tiemzone, because like all i18n no one thinks of if |
| 00:33 | <Hixie> | there are multiple balls? |
| 00:34 | <TabAtkins> | Lots of places do a ball drop, not just Times Square. |
| 00:34 | <TabAtkins> | And everyone likes to count down from 10, so... |
| 00:38 | <hober> | boblet: maybe. I hand-author hevents surprisingly frequently, so I have an Emacs command that inserts the correctly-formatted now timestamp for me |
| 00:38 | <hober> | I freely acknowledge I'm an outlier. :) |
| 00:39 | <boblet> | hober: yeah, I agree anyone hand-authoring should be using snippets (I do the same), but a surprising number of microformatters think that the brevity allowed is a good thing (eg implied n optimisation and the resulting i18n problems it has) |
| 00:40 | <boblet> | snippets ftw! |
| 00:49 | <Hixie> | the instructions for this lighter i am using say "do not use near fire, flame, or sparks" |
| 00:49 | <Hixie> | how the heck else am i supposed to use it |
| 00:49 | <TabAtkins> | The flame is part of use, so it doesn't count as something the lighter is used *near*. |
| 00:51 | <Hixie> | ok but once i've lit what i'm lighting... then it's on fire |
| 00:51 | <TabAtkins> | Yeah, so stop using it near that then. |
| 00:51 | <Hixie> | but it explicitly has a feature for lighting multiple things in a row |
| 00:51 | <Hixie> | like a bunch of candles |
| 00:51 | <TabAtkins> | Then I guess the definition of "near" comes into question. |
| 01:00 | <Philip`> | The idea is presumably that you're meant to disregard their instructions |
| 01:00 | <Philip`> | but that if you e.g. carry it into a burning building and it explodes then you can't sue them since they warned you in advance |
| 01:04 | <jamesr_> | TabAtkins: why would a hash function be slower in JS than in native code? |
| 01:04 | <TabAtkins> | Because most hashes are designed for a hardware implementation. |
| 01:05 | <Philip`> | JS runs on hardware |
| 01:05 | <TabAtkins> | Sigh. |
| 01:06 | <Philip`> | Maybe you mean most hashes are designed for implementation in languages that have 32-bit integer operations, or something? |
| 01:07 | <Philip`> | (That seems like the main pain with JS) |
| 01:07 | <TabAtkins> | Yeah. |
| 01:07 | <TabAtkins> | Ones that can actually sit next to the hardware if necessary. |
| 01:15 | <jamesr_> | JS has 32-bit integer operations, no? (i thought most bitwise ops truncate to 32 bits) |
| 01:16 | <Hixie> | TabAtkins: why couldn't a JS compiler be as efficient with hashing code as a C++ compiler? |
| 01:16 | <TabAtkins> | I assume it's more difficult, given that you don't have direct binary access. |
| 01:18 | <Philip`> | I suppose implementations might be clever enough to realise that "(a + b) & 0xffffffff" could do a 32-bit addition rather than storing intermediate values as doubles, but I don't know if any currently do that |
| 01:19 | <Philip`> | and it's a bit inelegant to rely on pattern-matching optimisations to make your code not terrible |
| 01:21 | <Hixie> | TabAtkins: i don't understand what "direct binary access" means |
| 01:22 | <TabAtkins> | Doing JS math involves using JS numbers. That abstraction is slower than just doing bit-munging like you can do in C and other languages. |
| 01:23 | <Hixie> | compilers can totally recognise that there's a function that only does math operations on its arguments and have a "fast version" compiled that they use when the input is in range |
| 01:24 | <Hixie> | isn't that a lot of what V8 actually does? |
| 01:27 | <jamesr_> | optimizing JS engines spend a lot of effort knowing when they can just bit-munge |
| 01:28 | <jamesr_> | and optimizing something like (a + b) & 0xff is not done using pattern matching |
| 01:29 | <TabAtkins> | I'd be happy to be shown wrong, that it's expected that we do fast hashing in js. |
| 01:29 | <jamesr_> | try it |
| 01:29 | <TabAtkins> | Aw, I wasn't wanting to implement one myself. >_< |
| 01:31 | <jamesr_> | generating a hash for a Blob's contents might make sense as a provided AP |
| 01:31 | <jamesr_> | I |
| 01:31 | <jamesr_> | or something of that nature |
| 02:12 | <roc> | modern engines absolutely do optimize "(a + b) & 0xffffffff" up the wazoo |
| 10:08 | <annevk> | can anyone think of a better repository than code.google.com/p/html5/ for the encoding data and scripts? |
| 10:08 | <annevk> | I don't really want to make a new one |
| 10:08 | <annevk> | oh, I guess I could use bitbucket |
| 10:58 | <annevk> | https://bitbucket.org/annevk/webencodings |
| 12:09 | <annevk> | http://annevankesteren.nl/2010/12/encodings-labels-tested has an explanation for gathering the data |
| 12:10 | <annevk> | and http://annevankesteren.nl/2010/12/encodings-analysis has some analysis |
| 12:12 | <hsivonen> | whoa, whoa. Does Chrome not have UI for selecting the character encoding or am I missing something? |
| 12:13 | <annevk> | on Mac there is View -> Encoding |
| 12:13 | <hsivonen> | annevk: I'm on Linux right now |
| 12:13 | <hsivonen> | oh. it's under a crazy level of submenus |
| 12:13 | <zcorpan> | under the menu button, Tools > Encoding |
| 12:14 | <annevk> | encoding menus are lame |
| 12:14 | <annevk> | I sort of wonder who is still subjected to them |
| 12:14 | <hsivonen> | I don't understand the encoding UI for Safari and Chrome |
| 12:14 | <hsivonen> | why is Auto Detect in the same set of choices as particular encodings? |
| 12:15 | <hsivonen> | that is, what are the semantics of choosing Auto Detect? |
| 12:15 | <hsivonen> | oh. it's not in the same set |
| 12:15 | <hsivonen> | confusing |
| 12:15 | <hsivonen> | it's a boolean outside the set |
| 12:16 | <hsivonen> | so if I choose Auto Detect in Chrome, how many bytes will Chrome sniff and how will it decide to commit to an encoding? will it ever reload a page because of autodetection? |
| 12:17 | <annevk> | dunno, there's no spec for sniffing :/ |
| 12:17 | <hsivonen> | I thought WebKit devs don't want to introduce charset reloads because of <meta> |
| 12:17 | <hsivonen> | there's now a bug about the HTML5 parser in Gecko running chardet only on the 1024 first bytes |
| 12:18 | <hsivonen> | the bug doesn't have sufficient site compat data and it's hard to judge it without |
| 12:19 | hsivonen | wishes Japanese Web authors got their encoding labeling act together |
| 12:27 | <zcorpan> | we should intentionally break non-utf-8 encodings in nightly builds to promote moving to utf-8 |
| 12:28 | <annevk> | disabling chardet in nightlies would be good |
| 12:28 | <hsivonen> | zcorpan: for authors to notice, you need to start publishing nightlies :-) |
| 12:28 | <annevk> | and Firefox and IE and Opera removing support for certain labels would be good too |
| 12:29 | <zcorpan> | hsivonen: well we need to start somewhere. some authors use nightlies, so they'll notice if their site broke |
| 12:29 | <annevk> | hmm, even Chrome supports ibm864 |
| 12:29 | <annevk> | Opera is left out |
| 12:29 | <hsivonen> | annevk: do Safari and Chrome have enough market share in the locales associated with those labels to draw conclusions about the needlessness of those labels? |
| 12:29 | <zcorpan> | hsivonen: oh, for opera, s/nightlies/weeklies/ |
| 12:31 | <annevk> | hsivonen, fair point |
| 12:31 | <annevk> | hsivonen, though for certain encodings only 1 browser supports them |
| 12:32 | <annevk> | hsivonen, e.g. Opera is the only browser with support for windows-sami-2 and viettcvn |
| 12:32 | <hsivonen> | annevk: hmm. I wonder how those got added in the first place. |
| 12:32 | <annevk> | Firefox is the only browser with ibm864i |
| 12:33 | <hsivonen> | annevk: the explanation in the case of Firefox is most likely that if you have IBM contributing i18n code, they contribute support for their own legacy stuff |
| 12:33 | <annevk> | also the only one with armscii-8 and csiso103t618bit, iso-ir-103, t.61-8bit, t.61 and csiso111ecmacyrillic, iso-ir-111, ecma-cyrillic |
| 12:33 | <annevk> | (search for OSIC to find them) |
| 12:33 | <hsivonen> | annevk: you should try to come up with a reason why those are a security threat to expedite removal |
| 12:34 | <annevk> | well, ": OSIC" is better |
| 12:34 | <annevk> | yeah, I have no idea how I get people to care about any of this :) |
| 12:35 | <hsivonen> | annevk: smontagu has been removing stuff piecemeal as people have come up with threat scenarios |
| 12:36 | <annevk> | what I'd love is for this to be fully deterministic |
| 12:37 | <annevk> | so I can always tell what would happen, regardless of browser |
| 12:37 | <annevk> | (and without browser being a input variable, obviously) |
| 12:53 | <annevk> | Safari has a weird pattern as well |
| 12:54 | <annevk> | for a number of encodings it seems to swap the code points 1A, 1C, 7F map to around |
| 12:56 | <hsivonen> | annevk: do you have a list of encodings that are supported but have no UI entry in the menu? |
| 12:57 | <annevk> | no, another list I lack is a mapping against IANA |
| 12:57 | <annevk> | also, I don't have multi-byte encodings covered |
| 12:58 | <annevk> | big5, shift_jis |
| 12:59 | <annevk> | inspecting those would require a different strategy |
| 13:20 | <hsivonen> | I'm shocked that html5lib doesn't have systematic tests for all void elements |
| 13:20 | <hsivonen> | I'll add some |
| 13:43 | <annevk> | one way would be of course to make HTML5 require certain encodings and mappings |
| 13:43 | <annevk> | it already defines error handling for UTF-8 |
| 13:44 | <annevk> | or make it normatively reference a "Web Encoding" spec |
| 14:27 | <hsivonen> | hmm. How do I file a bug against the Japanese Planet Debian? |
| 14:28 | hsivonen | tries the email on a blog on the same domain |
| 16:07 | <jacobolus> | TabAtkins: finally getting back to you a week or whatever later; I'm not precisely sure all of where your discussion happened, but is there a summary someplace of your compromises/agreements with the Apple people about gradient syntax? |
| 16:07 | <annevk> | hahaha "The WebSockets" |
| 16:08 | <annevk> | this reminds of that movie |
| 16:09 | <jacobolus> | annevk: link? |
| 16:09 | <annevk> | http://blogs.msdn.com/b/ie/archive/2010/12/21/html5-site-ready-and-experimental.aspx it also links to the movie |
| 16:10 | <annevk> | again Microsoft does some heavy PR-spin on how they made the right choice here... |
| 16:10 | <annevk> | so lame |
| 16:14 | <jacobolus> | annevk: "the movie" = http://www.xtranormal.com/watch/7991991/ ? |
| 16:15 | <annevk> | think so |
| 16:17 | <jacobolus> | annevk: you don't think microsoft just wants to "remove much of the guess work for developers"? |
| 16:17 | <jacobolus> | giving "more time for site developers to innovate and create better web experiences"? |
| 16:18 | <annevk> | it looks more like they were just late implementing Web Sockets and found some kind of way to make that look good |
| 16:18 | <annevk> | and now they use the same argument for a bunch of other things |
| 16:18 | <jacobolus> | cuteL "Other modules have perfectly fine interoperable alternatives, like using script in place of CSS3 Transitions and CSS3 Animations" |
| 16:19 | <jacobolus> | *cute: |
| 16:20 | <bga_> | are there IE developers here? |
| 16:20 | <jacobolus> | no one can accuse MS of being bad at FUD :) |
| 16:21 | <jacobolus> | "whatever we implemented? obviously important and awesome. whatever we didn't implement? probably half-baked and likely to break." |
| 16:22 | <bga_> | i have a problem with execCommand('SaveAs') :) |
| 16:22 | <bga_> | it do not save binary data |
| 16:28 | <jacobolus> | bga_: isn't it designed for text boxes or something? |
| 16:31 | <jacobolus> | bga_: SaveAs doesn't seem to be listed in http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#execCommand |
| 16:31 | <bga_> | i know :) |
| 16:32 | <bga_> | whatwg should invents such api :) |
| 16:33 | <annevk> | jacobolus, heh, put a PR-speak to English version of that on twitter |
| 16:34 | <bga_> | window.saveDialog(fileName, fileData, fileMime) |
| 16:34 | <jacobolus> | annevk: I don't believe in twitter; the translation sounds like a good idea though; surely someone is interested :) |
| 16:34 | <annevk> | I mean I did it for you |
| 16:35 | <annevk> | not sure yet whether I believe in twitter, but my friends post fun photos every now and then |
| 16:37 | <jacobolus> | toDataURL is the only way to get image data out of a canvas, right? |
| 16:37 | <jacobolus> | i.e. into JavaScript |
| 16:42 | <jacobolus> | that or pixel by pixel with createImageData I guess |
| 16:42 | <jacobolus> | er, getImageData |
| 16:42 | <jacobolus> | oh, nevermind |
| 16:56 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/746 -- browsers do funny things with elements inside <option> |
| 17:06 | <TabAtkins> | jacobolus: The changes I made due to Apple feedback were to make it easier to transition gradients. As a result I slightly simplified the first argument to linear gradients and added the explicit-radiuses form for radial gradients. |
| 17:07 | <jacobolus> | TabAtkins: so those changes are in the spec as it is online now? |
| 17:07 | <TabAtkins> | Yes. |
| 17:07 | <TabAtkins> | at dev.w3.org/csswg/css3-images |
| 17:07 | <jacobolus> | gotcha. so Apple is mostly on board with that as written? |
| 17:07 | <TabAtkins> | As far as I know, yeah. |
| 17:07 | <jacobolus> | ah, great |
| 17:08 | <jacobolus> | TabAtkins: how much does it differ from mozilla's current implementation? |
| 17:08 | <jacobolus> | are the syntaxes compatible, or a bit different? |
| 17:09 | <TabAtkins> | Yes, almost completely compatible. The only incompatible difference is if you used the explicit-starting-point form of linear gradients, for anything other than one of the sides or corners. |
| 17:09 | <TabAtkins> | That is, a gradient like linear-gradient(10px 10px, white, black) is no longer valid. |
| 17:09 | <TabAtkins> | But linear-gradient(top left, white, black) still is. |
| 17:10 | <jacobolus> | gotcha |
| 17:11 | <jacobolus> | TabAtkins: thanks |
| 17:22 | <Ms2ger> | annevk, you got me at "browsers do funny things" |
| 17:27 | <annevk> | heh |
| 17:30 | <annevk> | how exactly is MicroXML better than XML? |
| 17:31 | <hober> | so far it's not very different, is it |
| 17:32 | <oojacoboo> | anyone see the lunar eclipse last night? |
| 17:32 | <TabAtkins> | No. ;_; Too cloudy. |
| 17:33 | <oojacoboo> | yea, same here, too cloudy |
| 17:34 | <hober> | I think socal is going to float away from the mainland if this rain keeps up |
| 17:34 | <hober> | which is to say, it was completely overcast here too. :( |
| 17:36 | <oojacoboo> | man, a red moon, it would have been cool... for a min, I could have felt like I was living on a strange planet |
| 17:37 | <annevk> | whoa, no browser does incremental rendering of XML anymore? |
| 17:37 | <annevk> | http://www.hixie.ch/tests/evil/page-loading/incremental/001.cgi?mime=text%2Fxml&delay=1&repeats=20 |
| 17:37 | <annevk> | weak |
| 17:37 | <kennyluck> | Do people see junk on this page -> http://bugzilla.validator.nu/ ? |
| 17:38 | <oojacoboo> | kennyluck: junk? |
| 17:38 | <annevk> | it talks about Firefox 2... |
| 17:38 | <kennyluck> | Very weird but it seems to have some encoding problem. It works fine if I view it with Safari but I see junk from FF and IE. |
| 17:38 | <TabAtkins> | Man, js engines are *weird*. |
| 17:39 | <annevk> | Film at 11 |
| 17:39 | <TabAtkins> | I just changed the md5 implementation I found somewhere to do 32-bit addition on the full 32 bits, rather than splitting the numbers into 16-bit halves and then recombining, and it doubled execution time. |
| 17:41 | <TabAtkins> | ...in Firefox. In Chrome I see a 10% speedup from doing that. |
| 17:42 | <TabAtkins> | Sorry, 10% slowdown. Still, much better than a 100% slowdown. |
| 17:44 | <jcranmer> | so chrome sucks at doing 32-bit addition? |
| 17:44 | <TabAtkins> | Both browsers do. Chrome sucks much less. |
| 17:45 | <jcranmer> | too early in the afternoon for me |
| 17:46 | <TabAtkins> | Unless your whois is lying, it's not the afternoon at all for you! |
| 17:46 | <jcranmer> | it's 12:51 PM |
| 17:46 | <TabAtkins> | Oh, I see, that's just the freenode server you're connecting through that's in Oregon. |
| 17:46 | <jcranmer> | the server I'm connected to is in Oregon |
| 17:47 | <TabAtkins> | I wasn't looking too closely. |
| 17:47 | <jcranmer> | the server my irc client is on is in the DC area |
| 17:47 | <jcranmer> | the computer I'm typing this on is a few miles further to the south |
| 17:47 | <ap> | annevk: do you know about <http://demo.icu-project.org/icu-bin/convexp?s=IANA&s=MIME&s=ALL>;? |
| 17:48 | <ap> | annevk: most WebKit encodings come from there, modulo a few handcrafted additions, and tweaks Google made in their distribution for some reason |
| 17:49 | <annevk> | Chrome is quite different from Safari |
| 17:49 | <annevk> | and Mac Safari is different from Win Safari |
| 17:49 | <annevk> | well, that is, Chrome has much more encodings disabled |
| 17:56 | <ap> | annevk: yes, we don't support some legacy encodings in Safari on Windows, and may be shipping a different version of ICU, depending on which version of Mac OS X you tested with |
| 17:56 | <ap> | annevk: the reason is that besides Web compatibility, we need to be read old local files on Mac |
| 17:57 | <ap> | s/be// |
| 17:57 | <annevk> | I have the latest Mac OS X |
| 17:58 | <annevk> | Yeah, apparently Mac Opera supports some more Mac encodings for that reason too |
| 17:58 | <annevk> | Though a lot less than Safari, and on Windows we support no Mac encodings despite most other browsers supporting at least a few |
| 17:58 | <annevk> | It's not just Mac encodings though |
| 17:59 | <annevk> | Chrome 28 / Safari 46 ... |
| 18:00 | <ap> | annevk: do you have any outrageous examples that I would want to fix? |
| 18:00 | <annevk> | sorry :/ |
| 18:00 | <annevk> | I only have http://annevankesteren.nl/2010/8-bit-labels so far |
| 18:00 | <ap> | annevk: by the way, WebKit nightlies are quite different from shipping Safari in how they match alias names |
| 18:00 | <ap> | annevk: we used to ignore all punctuation, but we no longer do |
| 18:01 | <annevk> | well, and the original data on Bitbucket; I need to find some way to query it more intelligently |
| 18:01 | <annevk> | ap, ah great, Opera changed away from that too |
| 18:01 | <ap> | annevk: chromium probably shipped that already, which is why they may seem more different in your data than they actually are |
| 18:02 | <annevk> | it would mean that would match less labels and produce less encodings |
| 18:02 | <annevk> | so I'm not sure that theory holds |
| 18:02 | <ap> | well, fewer aliases for the same encodings |
| 18:03 | <annevk> | I feed 300 labels; I count unique encodings and aliases for them |
| 18:03 | <annevk> | oh yeah |
| 18:03 | <annevk> | they would end up among "obviouslyfake" in my data |
| 18:03 | annevk | looks |
| 18:04 | <annevk> | Chrome has indeed quite a bit more than Safari there |
| 18:06 | <ap> | annevk: another change you can find in WebKit nightlies is that we now drop names with version info that come from ICU, such as ISO_2022,locale=ja,version=0 |
| 18:07 | <annevk> | that was a label WebKit recognized? |
| 18:07 | <annevk> | wow |
| 18:08 | <annevk> | I sort of hope we can just have a fixed list of labels that you need to have for the web and no more |
| 18:08 | <annevk> | maybe grandfathering the Mac encodings in... |
| 18:09 | <annevk> | then implementations can also be a lot simpler than all of ICU |
| 18:10 | <ap> | annevk: so far, the most practically data that came from encoding support research was about upgrading encodings |
| 18:10 | <ap> | annevk: such as "EUC-KR really means windows-949" |
| 18:11 | <annevk> | yeah, that was great |
| 18:11 | <annevk> | oh actually, I did find a few funny things in Safari |
| 18:12 | <Ms2ger> | Don't we all sometimes? |
| 18:12 | <annevk> | ap, http://annevankesteren.nl/2010/8-bit-labels#cp869 Safari has this for quite a few encodings, swapping 1A, 1C, and 7F around |
| 18:12 | <annevk> | http://annevankesteren.nl/2010/8-bit-labels#ibm775 (an encoding only Safari and Internet Explorer have) |
| 18:12 | <annevk> | (same weirdness) |
| 18:13 | <annevk> | goes for most IBM encodings I think |
| 18:13 | <annevk> | (scroll upwards) |
| 18:14 | <ap> | annevk: swapping is interesting - it comes from ICU http://demo.icu-project.org/icu-bin/convexp?conv=ibm-869_P100-1995&s=IANA&s=MIME&s=ALL |
| 18:15 | <annevk> | ah yeah, whenever Chrome does not have the encoding disabled it has the same issue |
| 18:15 | <ap> | annevk: I'll file a bug for our ICU folks to look into, but I suspect that this is a bug in Windows |
| 18:16 | <ap> | annevk: as IBM probably checked ICU to match their original definition of those encodings |
| 18:16 | <annevk> | if the tables just say "S" it means Safari on both Mac and Win |
| 18:16 | <annevk> | and Firefox and Internet Explorer contradict Safari |
| 18:16 | <annevk> | e.g. in http://annevankesteren.nl/2010/8-bit-labels#cp862 |
| 18:17 | <annevk> | or http://annevankesteren.nl/2010/8-bit-labels#ibm857 |
| 18:17 | <annevk> | I wonder if Chrome and Opera need to support these IBM encodings |
| 18:17 | <ap> | oh, an example that's supported by more than just Ie is helpful |
| 18:18 | <annevk> | I would sort of expect Firefox to do what IBM wants |
| 18:18 | <ap> | annevk: looking at 862 specifically, Safari probably supports many more aliases for it, according to that ICU page |
| 18:18 | <annevk> | but then ICU not doing what IBM wants would also be weird |
| 18:19 | <annevk> | ap, I guess I can try to increase the amount of aliases to 400 |
| 18:19 | <annevk> | I haven't even gone through the IANA registry either yet |
| 18:56 | <hsivonen> | annevk: are you sure all browsers regressed xml loading instead of the test breaking? |
| 18:57 | <hsivonen> | TabAtkins: did you test JägerMonkey or something older for 32-bit arithmetic? |
| 18:57 | <hsivonen> | TabAtkins: I'd expect trunk to do 32-bit math faster than beta6 or earlier |
| 18:57 | <TabAtkins> | hsivonen: I have no idea. I'm using b7. |
| 18:58 | <hsivonen> | TabAtkins: odd |
| 18:58 | <TabAtkins> | The function in question is this: |
| 18:58 | <TabAtkins> | var lsw = (x & 0xFFFF) + (y & 0xFFFF); |
| 18:58 | <TabAtkins> | var msw = (x >> 16) + (y >> 16) + (lsw >> 16); |
| 18:58 | <TabAtkins> | return (msw << 16) | (lsw & 0xFFFF); |
| 18:58 | <TabAtkins> | And I tried replacing it with just: |
| 18:59 | <TabAtkins> | return ( (x & 0xFFFFFFFF) + (y & 0xFFFFFFFF) ) & 0xFFFFFFFF; |
| 18:59 | <TabAtkins> | Which, come to think of it, is probably incorrect anyway. |
| 18:59 | <TabAtkins> | It didn't change the md5 for the strings I was testing, at least. |
| 19:00 | <annevk> | hsivonen, good point, no |
| 19:00 | <hsivonen> | TabAtkins: the latter could overflow out of 32 bits for the intermediate value, right? |
| 19:00 | annevk | makes a local test |
| 19:00 | <TabAtkins> | hsivonen: Yes. |
| 19:00 | <bga_> | wow |
| 19:01 | <bga_> | ((x|0) + (y|0))|0 |
| 19:01 | <hsivonen> | TabAtkins: I think the original correctly lets overflow wrap around |
| 19:02 | <TabAtkins> | hsivonen: Yes, it does. |
| 19:02 | <TabAtkins> | hsivonen: My version is incorrect as written. |
| 19:02 | <TabAtkins> | bga_: How does |0 work? Do bitwise operators automatically truncate to 32 bits or something? |
| 19:02 | <bga_> | yes |
| 19:03 | <bga_> | convert to `long` |
| 19:03 | <bga_> | ~~x too |
| 19:03 | <TabAtkins> | Ah, kk. Didn't realize that, so I using a more generically correct version. |
| 19:04 | <TabAtkins> | Let me try out a correct variant. |
| 19:06 | <TabAtkins> | All right, it's back to a wash with "var tmp = ~~x + ~~y; return (tmp>>>32) || tmp;" |
| 19:06 | <bga_> | (tmp>>>32)? |
| 19:07 | <bga_> | it always 0 |
| 19:08 | <TabAtkins> | No, x+y can be greater than 32 bits. |
| 19:08 | <TabAtkins> | Frex, if both of them are 2^32 - 1. |
| 19:08 | <annevk> | hsivonen, hmm yeah, all browsers do it incrementally |
| 19:09 | <annevk> | better fix my post |
| 19:10 | <bga_> | TabAtkins read es spec |
| 19:10 | <bga_> | x >>> 32 <=> x >>> 0 |
| 19:11 | <bga_> | x >>> y <=> long(x) >>> long(y)&31 |
| 19:11 | <TabAtkins> | Oh, hrm, you're right. I guess I need to explicitly use numeric comparisons then. |
| 19:14 | <hsivonen> | annevk: you might be interested in the xml-dev threads on MicroXML |
| 20:15 | <annevk> | hsivonen, anything in particular? |
| 20:15 | <annevk> | hsivonen, I did go through some of the email |
| 20:37 | <hober> | is xml-dev worth subscribing to? |
| 20:37 | <Philip`> | TabAtkins: "return (tmp>>>32) || tmp" - should that be |, not ||? |
| 20:51 | <TabAtkins> | Philip`: No, I was using logical or on purpose to do fallback. But that line was completely wrong in the first place, because my brain was being stupid and forgetting what "overflow" means'. |
| 23:26 | <oojacoboo> | do you really not have to close out the <th> and <td> elements in a table? |
| 23:27 | <TabAtkins> | Yup. |
| 23:27 | <TabAtkins> | You also don't have to close <li>s. |
| 23:27 | <oojacoboo> | assuming that html4 or 5 and not xhtml |
| 23:27 | <TabAtkins> | There are some crazy rules about when you dont' ahve to close <p>, so I ignore them and just always explicitly close it. |
| 23:27 | <TabAtkins> | Yes, xhtml needs to be well-formed xml. No omitted tags. |
| 23:28 | <oojacoboo> | seems kinda dangerous all around to me, but w/e |
| 23:28 | <TabAtkins> | You don't need to close the <thead>/<tbody>/<tfoot> elements either. |
| 23:28 | <oojacoboo> | interesting |
| 23:28 | <TabAtkins> | Nah, it's cool. Check out, for example, this page's source: http://www.xanthir.com/diagrams/flex-align-diagrams.html |
| 23:29 | <oojacoboo> | I guess since they are never nested, makes sense |
| 23:29 | <oojacoboo> | actually looks pretty clean... |
| 23:29 | <TabAtkins> | Yeah, they're never nested without a container protecting the nested one from the outer one. |
| 23:30 | <oojacoboo> | yea |
| 23:31 | <oojacoboo> | are there any plans to introduce some sort of child header element for a <tbody> ? |
| 23:31 | <TabAtkins> | Huh? |
| 23:32 | <oojacoboo> | imagine a table with multiple sections, <tbody>s, where you wanted to include a line describing what the contents of each section are |
| 23:32 | <TabAtkins> | Use a <tr> with a colspanning <th>. |
| 23:33 | <oojacoboo> | yea |
| 23:34 | <oojacoboo> | not quite the same, but w/e |
| 23:34 | <oojacoboo> | I was thinking something more like <caption> |