| 07:26 | <zcorpan> | annevk: it looks weird to mix decimal and hex |
| 07:28 | <zcorpan> | annevk: also, editorial, − looks better than - |
| 07:34 | <zcorpan> | do we need to have serializers for all encodings? |
| 07:56 | <annevk> | zcorpan: is there a better +? |
| 07:56 | <annevk> | zcorpan: and mixing decimal and hex makes sense there |
| 08:05 | <zcorpan> | + is fine |
| 08:06 | <zcorpan> | how does it make sense? |
| 08:06 | <annevk> | one is a code point and the other is an index |
| 08:06 | <annevk> | in an array of 94n length |
| 08:08 | <zcorpan> | ↪0x81 |
| 08:08 | <zcorpan> | 8648 |
| 08:08 | <zcorpan> | ↪0xA0 |
| 08:08 | <zcorpan> | 0xF8F0 |
| 08:08 | <zcorpan> | how do you explain this, andrew? |
| 08:09 | <annevk> | the first is an index into a table, the second is a code point? |
| 08:10 | <annevk> | 8648 = 92*94 |
| 08:10 | <annevk> | though I think that has to be come 188 lower (all of them) |
| 08:10 | <zcorpan> | and 0xF8F0 is not an index? |
| 08:10 | <annevk> | no |
| 08:11 | <zcorpan> | ok, then i'm confused |
| 08:11 | <zcorpan> | "The shift_jis lead octet index for a given octet is:" |
| 08:11 | <annevk> | I didn't want to name it the shift_jis lead octet index or code point for a given octet |
| 08:12 | <annevk> | but I could I suppose |
| 08:13 | <zcorpan> | ok, i see now in the to Unicode algorithm that 0xF8F0 and above will equal the code point |
| 08:13 | <annevk> | and the second should prolly be named shift_jis offset rather than trail octet index |
| 08:14 | <zcorpan> | but i don't see why that should mean that it's fine to mix decimal and hex |
| 08:14 | <annevk> | also 0xE000 |
| 08:15 | <zcorpan> | before the to Unicode algorithm, it's just an opaque number |
| 08:16 | <annevk> | I think this is easier if you want to review what the algorithm does |
| 08:34 | <hsivonen> | I wonder how bad an idea it would be to autodetect UTF-8 vs. locale-specific legacy encoding by seeing if the first non-ASCII byte and up to 3 bytes after it form a valid UTF-8 byte sequence |
| 08:35 | <hsivonen> | that is, are there valid UTF-8 byte sequences that can reasonably occur in single-byte encodings? |
| 08:35 | <annevk> | What is the problem? |
| 08:35 | <hsivonen> | annevk: letting people publish UTF-8 content while being too inept to declare it |
| 08:37 | <annevk> | there are some legacy encodings that have valid octets for the whole range |
| 08:37 | <annevk> | e.g. windows-1252 |
| 08:37 | <annevk> | or windows-1254 |
| 08:37 | <annevk> | 1256 too |
| 08:37 | <annevk> | etc. |
| 08:38 | <hsivonen> | annevk: yes, but in the case of Windows-1252, UTF-8 byte sequences don't seem to result in sensible natural language when decoded as Windows-1252 |
| 08:38 | <hsivonen> | dunno about 1254 and 1256 |
| 08:38 | <zcorpan> | doesn't opera have heuristics to detect utf-8? |
| 08:38 | <hsivonen> | zcorpan: interesting. from how many bytes? |
| 08:39 | <zcorpan> | no idea |
| 08:39 | <Philip`> | hsivonen: What about pages that concatenate a small amount of UTF-8 content and a large amount of legacy-encoding content? |
| 08:39 | <Philip`> | They'll definitely look like UTF-8 at first, but that might not be the desired way to decode them |
| 08:40 | <hsivonen> | Philip`: well, yeah, such pages are broken no matter what, but the degree of perceived brokenness could vary, sure |
| 08:43 | <hsivonen> | anyway, adding UTF-8 autodetection would not advance the goal Faruk had at the start of the thread |
| 08:44 | <hsivonen> | adding UTF-8 autodetection would only allow UTF-8-using authors to declare less |
| 08:44 | <annevk> | and only if you happen to use it in the first 1024 octets? |
| 08:48 | <hsivonen> | annevk: no, anywhere |
| 08:49 | <hsivonen> | annevk: the bytes before the first-non-ASCII byte can be decoded as US-ASCII, so there's no need to stall processing except to wait for the 3 bytes after the first non-ASCII byte when the first non-ASCII byte is seen |
| 08:50 | <hsivonen> | annevk: anyway, it's not at all clear that the problem this would solve is worth solving |
| 08:52 | <annevk> | oh |
| 08:52 | <annevk> | conceptually I guess it's not that complicated, but it's still kind of sucky |
| 09:15 | <hsivonen> | annevk: (Re: old IRC logs) It's very likely that there are bugs in Gecko's charset alias list |
| 09:50 | <zcorpan> | hsivonen: apparently we detect as utf-8 if there are 10 or more valid utf-8 byte sequences and no invalid utf-8 byte sequences |
| 09:52 | <gsnedders> | zcorpan: At the start? |
| 09:54 | <hsivonen> | zcorpan: I take it that valid byte sequences mean multibyte sequences so that 10 ASCII bytes don't count. |
| 09:55 | <hsivonen> | zcorpan: can there be an arbitrary number of ASCII bytes between the UTF-8 byte sequences? |
| 09:55 | <zcorpan> | right |
| 09:55 | <hsivonen> | zcorpan: how does incremental parsing and rendering work before the sniffer has made its decision? |
| 09:56 | <zcorpan> | *shrug* |
| 09:57 | <hsivonen> | zcorpan: that's the most interesting part! |
| 09:59 | <zcorpan> | if it's very interesting, i guess you could reverse engineer it :-P |
| 10:01 | <zcorpan> | apparently we reparse if the detector makes a decision late |
| 10:02 | <hsivonen> | zcorpan: ok. Thanks. I want to avoid introducing reparsing to locales that don't already have it as much as possible. |
| 10:03 | <hsivonen> | I tried to remove reparsing from the locales that have it in the Firefox 4 cycle, but then the Japanese Planet Debian broke and people got worried |
| 10:04 | <hsivonen> | the Japanese Planet Debian has fixed its encoding declaration since then |
| 10:05 | <zcorpan> | would be really nice if reparsing could be nuked |
| 10:05 | <hsivonen> | also, I want to avoid making the encoding determination timing-dependent |
| 10:05 | <hsivonen> | people seem to believe that our feedback loop from Japan is broken, so decisions get made based on rumors and existence proof |
| 10:19 | <zcorpan> | wow, an email from 2002 just made it to the list |
| 10:19 | <zcorpan> | oh sorry, that was part of the email address |
| 10:26 | <jgraham> | But the content was about DTD so I can understand your confusion! |
| 10:26 | <hsivonen> | do we have a FAQ entry about DTDs? |
| 10:29 | <zcorpan> | http://wiki.whatwg.org/wiki/FAQ#Under_what_conditions_should_a_DOCTYPE_be_used_in_XHTML.3F - i guess not enough |
| 10:30 | <zcorpan> | though it links to validator.nu faq, which may be enough |
| 11:53 | <annevk> | are [TreatUndefinedAs=EmptyString] or [TreatUndefinedAs=Null] actually used? |
| 11:54 | <Ms2ger> | Yes |
| 11:54 | <Ms2ger> | In HTML/Obsolete, IIRC |
| 11:54 | <Ms2ger> | Oh |
| 11:54 | <Ms2ger> | Undefined? Not sure |
| 11:55 | <annevk> | no hits |
| 11:55 | <annevk> | in HTML anyway |
| 11:56 | <Ms2ger> | Mozilla does support it, IIRC |
| 11:56 | <hsivonen> | annevk: why aren't UCS2 names defined as aliases of UTF-16? |
| 11:57 | <hsivonen> | annevk: so is the plan to make BOM override HTTP so that UTF-16BE with little-endian BOM is decoded as little-endian? |
| 11:58 | <hsivonen> | annevk: fwiw, in case there are bugs in how Gecko handles BOMs in HTML, it's because I was naive enough to assume that the decoder library worked per spec |
| 11:58 | <annevk> | hsivonen: are they in any browser? UTF-16 labels are not really done yet, every browser has them done differently |
| 11:58 | <annevk> | hsivonen: Basically yes, BOM "rules" |
| 11:59 | <hsivonen> | annevk: by source inspection, it seems that Gecko supports crazy UCS2 aliases |
| 11:59 | <hsivonen> | annevk: IIRC, a legacy SonyEricsson browser did, too |
| 11:59 | <hsivonen> | not that it matters |
| 12:00 | <annevk> | hsivonen: I think what put me off was that Gecko added them to BE |
| 12:00 | <hsivonen> | UTF-16 is one of those things that must have seemed great ideas before implementation experience |
| 12:00 | <annevk> | hsivonen: not UTF-16 |
| 12:00 | <hsivonen> | annevk: UCS2 was BE in theory, no? |
| 12:01 | <annevk> | oh okay |
| 12:01 | <annevk> | I think per http://wiki.whatwg.org/wiki/Web_Encodings only Gecko had those labels |
| 12:01 | <annevk> | but I'm fine with adding labels |
| 12:02 | <annevk> | oh no, so Opera has those labels too, but added to UTF-16 |
| 12:02 | <hsivonen> | annevk: if the Web doesn't need them and smontagu agrees, I'm OK with getting rid of those labels |
| 12:02 | <annevk> | but I guess with UTF-16 now defaulting to LE that does not make sense |
| 12:02 | <hsivonen> | annevk: the question is whether there's legacy content |
| 12:02 | <annevk> | hsivonen: IE has this " iso-10646-ucs-2, ucs-2, unicode, utf-16, utf-16le" as labels for utf-16 |
| 12:02 | <hsivonen> | annevk: not what makes sense |
| 12:02 | <annevk> | agreed |
| 12:03 | <hsivonen> | annevk: so iso-10646-ucs-2 is LE in IE? |
| 12:03 | <annevk> | I would expect so based on that data |
| 12:07 | <hsivonen> | inspired by the thread Faruk started, a console warning about form submissions using encodings that can't represent all of Unicode has landed on mozilla-central and will be in the next Nightly build |
| 12:07 | <hsivonen> | I wonder if it has any impact on anything at all |
| 12:07 | <hsivonen> | I hope it does |
| 12:08 | <hsivonen> | and I hope people don't complain too much about Firefox whining about bad authoring practices |
| 12:08 | <Ms2ger> | And that Nightly also won't support geostd8 |
| 12:08 | <annevk> | I thought those changes were great |
| 12:09 | <hsivonen> | Ms2ger: is geostd8 an encoding? |
| 12:09 | <annevk> | was :p |
| 12:09 | <Ms2ger> | Yes, something Georgian nobody supports |
| 12:09 | <hsivonen> | hooray! |
| 12:16 | <annevk> | I think the way the BOM stuff should work by the way is that you say "decode X using label Y" and that algorithm first checks if X has a BOM and then picks utf-8/utf-16/utf-16be if there is a BOM, and otherwise uses Y to pick an encoding |
| 12:18 | <hsivonen> | annevk: what's your plan for integrating format-specific internal encoding declarations to the algorithms? |
| 12:19 | <annevk> | well before HTML starts decoding it first does this search through a bunch of octets |
| 12:19 | <annevk> | and if finds a label there it can then use that |
| 12:19 | <hsivonen> | annevk: FWIW, even though I previously WONTFIXed a theory-based bug about the precedence of the BOM, I'm OK with changing the precedence now that there are examples of real pages in the wild where it matters |
| 12:19 | <annevk> | cool |
| 12:27 | <annevk> | heh, found an old page by Lachy http://wiki.whatwg.org/wiki/Character_Encoding_Detection |
| 12:28 | <Lachy> | I don't remember writing that. |
| 12:29 | <hsivonen> | the Mozilla observations look weird, but I'm willing to believe the old parser did weird things |
| 12:29 | <Lachy> | hmm. Did it in December 2006. That's 5 years ago |
| 12:31 | <annevk> | http://wiki.whatwg.org/wiki/StringEncoding seems kind of nonsensical to me to expose that many encodings to script authors |
| 12:32 | <annevk> | especially with the addition of allowing user agents to allow arbitrary encodings |
| 12:34 | <hsivonen> | annevk: that seems bad |
| 12:34 | <hsivonen> | annevk: has it been proposed on a mailing list? |
| 12:34 | <annevk> | dunno, I don't remember seeing it |
| 12:34 | <annevk> | apart from on the wiki that is |
| 12:35 | <hsivonen> | annevk: the API design is questionable, too |
| 12:35 | <hsivonen> | it turns out that it's really hard to get the API right |
| 12:36 | <hsivonen> | iconv gets the API wrong |
| 12:36 | <hsivonen> | the Gecko-internal decoders get the API wrong |
| 12:36 | <hsivonen> | Java gets the API right |
| 12:37 | <annevk> | I hope the Encoding Standard gets it right, though it does not expose it to that level of detail currently |
| 12:37 | <Ms2ger> | And Java gets the performance wrong? :) |
| 12:37 | <hsivonen> | so if you see a design that doesn't have the characteristics of the Java NIO API, it makes sense to suspect there's an API design error |
| 12:37 | <hsivonen> | Ms2ger: not that I'm aware |
| 12:37 | <Ms2ger> | Then how do I get to whine about Java? :) |
| 12:37 | <annevk> | pointer to that API? |
| 12:42 | <hsivonen> | ICU4C seems to get the API right |
| 12:43 | <hsivonen> | annevk: http://docs.oracle.com/javase/6/docs/api/java/nio/charset/CharsetDecoder.html |
| 12:43 | <hsivonen> | annevk: the key being that it's necessary to be able to signal "no more input" to the decoder |
| 12:44 | <hsivonen> | iconv and Gecko fail at that |
| 12:44 | <hsivonen> | for example, if a file ends with an incomplete UTF-8 byte sequence, you don't see a REPLACEMENT CHARACTER for the trailing incomplete sequence in Firefox |
| 12:45 | <annevk> | ah yes |
| 12:45 | <annevk> | I introduced a "EOF octet" concept for that |
| 13:08 | <annevk> | though I have not made shift_jis emit an explicit U+FFFD in such cases |
| 13:08 | <annevk> | neither Gecko nor IE did that... |
| 13:34 | <zcorpan> | gecko and presto don't emit U+FFFD for trailing half utf-8 byte sequence, but both consider that a bug |
| 13:34 | <eightfold> | howdy |
| 13:34 | <eightfold> | is it likely that the HTML5 specification will be finalized without specifying a standardized video and audio format? |
| 13:34 | <zcorpan> | (except opera does it right in websockets because i tested for that and emoller fixed it for websockets) |
| 13:35 | <jgraham> | eightfold: Yes |
| 13:35 | <jgraham> | Well no |
| 13:35 | <jgraham> | The specification will never be finalized |
| 13:35 | <jgraham> | Except in some meaningless W3C way |
| 13:36 | <jgraham> | As long as people are still implementing it, the HTML standard will keep evolving along a continuum |
| 13:36 | <eightfold> | jgraham: yes, but it will be finalized the meaningless W3C way? |
| 13:36 | <MikeSmith> | annevk: how about we make the URL spec a WebApps deliverable instead? |
| 13:36 | <eightfold> | "finalized the" = "finalized in the" |
| 13:37 | <annevk> | MikeSmith: what about the charter? |
| 13:37 | <jgraham> | The video codec won't be mandated in whatever W3C pushes to Rec. |
| 13:37 | <annevk> | MikeSmith: maybe we should first write the spec and then see who wants to publish it... |
| 13:38 | <MikeSmith> | annevk: working on that now |
| 13:38 | <annevk> | sweet |
| 13:38 | <MikeSmith> | about the charter, I guess we'd need to propose it |
| 13:38 | <annevk> | zcorpan: interesting |
| 13:38 | annevk | is playing with euc-jp decoding |
| 13:38 | <annevk> | it's somewhat more sane than shift_jis, but more complex |
| 13:38 | <Philip`> | eightfold: Meaningless finalisation will require some impossible tasks to be completed (like a comprehensive test suite and comprehensively interoperable implementations), so it'll depend on whether those requirements get dropped or ignored or whether they block progress forever |
| 13:38 | <eightfold> | jgraham: what is the "Rec."? recommendation? |
| 13:38 | <jgraham> | Yes |
| 13:39 | <Ms2ger> | Ignored, I guess |
| 13:40 | <eightfold> | but does anyone here believe there will ever be a common video format among browser vendors? |
| 13:40 | <zcorpan> | i hope there will be! |
| 13:41 | <zcorpan> | but who doesn't |
| 13:41 | <eightfold> | yes, i sure do too. |
| 13:41 | <jgraham> | No point in letting unreasoble requirements get in the way of celebrating finishing a legacy technology |
| 13:42 | <eightfold> | microsoft and apple doesn't seem to be very eager to implement webm support. at least i realized the >ie9 solution seems to simplify the installation of a browser plugin. |
| 13:42 | eightfold | will brb |
| 13:44 | <hsivonen> | WebM support for IE9 isn't really a browser plug-in |
| 13:45 | <hsivonen> | it's an extension component for the system-wide media framework |
| 13:45 | <hsivonen> | different layer of extension |
| 13:45 | <hsivonen> | different API |
| 13:53 | <bga> | https://github.com/jterrace/js.js |
| 13:53 | <bga> | %) |
| 14:07 | <MikeSmith> | "It currently takes about 40 seconds to run print(1+1)." |
| 14:16 | <eightfold> | hsivonen: that was what i was trying to say, but didn't. :) what does the process look like to the end user? i don't have a windows installation handy. |
| 14:27 | <eightfold> | is there any chance w3c will recommend h.264 in the html5 spec, given it's proprietary nature? |
| 14:27 | <eightfold> | its |
| 14:30 | <smaug____> | eightfold: I guess only if h.264 becomes royalty-free |
| 14:33 | <eightfold> | smaug____: MPEG-LA has said that it will be forever, but only for end users, right? so software that implements h.264 still has to pay? |
| 14:33 | <eightfold> | "it will be" = "it will be free" |
| 14:35 | <zewt> | that's the same thing, heh |
| 14:36 | <eightfold> | oops |
| 14:37 | <smaug____> | eightfold: it must be free for implementors |
| 14:38 | <eightfold> | smaug____: for w3c to recommend it, you mean? |
| 14:39 | <zewt> | there are endless places they can drop in licensing (encoders, decoders, per type of media encoded, for streaming, etc) |
| 14:40 | <smaug____> | eightfold: there are w3c members which certainly won't accept recommendation which includes non-free parts |
| 15:36 | <hsivonen> | eightfold: to get WebM for IE9, you go to a Web page, download an installer .exe and run it as administrator |
| 15:36 | <hsivonen> | eightfold: the experience is the usual Windows software installation experience |
| 15:37 | <hsivonen> | eightfold: MPEG-LA wants royalties from encoders, decoders and from a subset of people who distribute bits arranged with an H.264 encoder |
| 15:38 | <hsivonen> | eightfold: for H.264 to be properly royalty-free, it needs to be royalty-free to decode, to encode and to transfer |
| 15:38 | <zewt> | if you ever hear the MPEG-LA offering anything for "free", double-check--the entire *point* of the MPEG-LA is to license MPEG stuff for money |
| 15:39 | <zewt> | they're not going to do anything just to be nice |
| 15:39 | <hsivonen> | eightfold: where encode and decode are shorthand for making, distributing and running decoder/encoder |
| 15:41 | <zewt> | (though I could just almost see them offering a hamstrung profile for free, just to try to cripple competing free codec development) |
| 15:58 | <gsnedders> | zewt: There are plenty of members of MPEG-LA and the MPEG WG who want there be a RF standard. Apple is one of the most vocal. |
| 15:59 | <gsnedders> | (And don't think Apple are just saying that after the Ogg/Theora stuff going everywhere: they were vocal about this at the time H.264 was being standardized a decade ago.) |
| 15:59 | <hsivonen> | gsnedders: they were vocal about MPEG-4 (Visual) Simple Profile before H.264 |
| 16:00 | <gsnedders> | And I believe about stuff before that too. |
| 16:00 | <gsnedders> | But yeah, that there are patent holders pushing for a RF baseline isn't new, but it's no more likely to happen now than a decade ago. |
| 16:01 | <gsnedders> | Also, as foolip has pointed out multiple times, without an audio codec and the container becoming RF, it doesn't matter much as you don't gain compat. with existing toolchains. |
| 16:01 | <zewt> | and of course it would be a reduced profile |
| 16:01 | <hsivonen> | gsnedders: so much so that the release of QuickTime 6 was delayed, because Apple tried to get the stuff made royalty-free |
| 16:02 | <hsivonen> | (of course, when you have shown you have the software ready to ship, it's not particularly credible to withhold it for a short while. they know you are going to ship it) |
| 16:02 | <erlehmann> | gsnedders, if apple cares about royalty free standards now, why haven't they supported vorbis when everyone else does? explain. |
| 16:03 | <gsnedders> | "Apple agrees with paying a reasonable royalty for including MPEG-4 codecs in QuickTime, but does not believe that MPEG-4 can be successful in the marketplace if content owners must also pay royalties in order to deliver their content using MPEG-4." |
| 16:03 | <hsivonen> | gsnedders: you'd gain compat with existing chips |
| 16:03 | <gsnedders> | hsivonen: True, but I get the impression that stuff is starting to move on mobile to where it is on TVs: having DSPs reprogrammable. |
| 16:04 | <gsnedders> | erlehmann: There are plenty of reasons why they might not have done so; it's hard to speculate. |
| 16:04 | <erlehmann> | aren't they already? see the OMAP work. |
| 16:04 | <hsivonen> | gsnedders: reprogrammable by whom |
| 16:04 | <erlehmann> | gsnedders, i thought you might be more in the know than me. |
| 16:04 | <gsnedders> | erlehmann: Most mobile devices ship with locked-down DSPs. Certainly OMAP devices in general have unlocked DSPs, not sure about mobile applications of them. |
| 16:04 | <gsnedders> | hsivonen: Anyone whom the OS allows access to the chips to. |
| 16:05 | <hsivonen> | gsnedders: if the chip vendor gives you enough documentation and toolchain |
| 16:05 | <gsnedders> | hsivonen: Sure, but for most Android devices that's probably enough. |
| 16:06 | <gsnedders> | hsivonen: Because WebM is now part of the standard Android impl |
| 16:06 | <hsivonen> | gsnedders: does Android let apps push code to the DSP? |
| 16:06 | <gsnedders> | hsivonen: I believe not. But I believe everyone who does WebM decoding uses the Android's native support. |
| 16:06 | <zewt> | hardware on android tends to be hidden behind magic proprietary .so's or hidden away on the locked-down radio side of things |
| 16:06 | <zewt> | it'd be the vendor who would have to implement it |
| 16:07 | <hsivonen> | gsnedders: is it so much part of the standard Android impl that Opera is going to let it show in canPlayType? |
| 16:07 | <gsnedders> | (Though our experience has been WebM support often interacts badly with hardware-accelerated drawing in a lot of cases.) |
| 16:09 | <gsnedders> | (i.e., WebM's support in Android on many devices is buggy) |
| 16:10 | <gsnedders> | Apparently it often draws in the wrong place, for example. |
| 16:14 | <zewt> | heh, second time google search has wonked up the cursor position while i was typing a search |
| 16:19 | <gsnedders> | hsivonen: Somehow Google needs to better ensure Android devices don't have horrible bugs like that :\ |
| 16:20 | <zewt> | they can't even get android devices to use a standard button layout, so ... |
| 16:43 | <gsnedders> | erlehmann: A few possible reasons: they don't feel their customers require it; they don't think another format that exists for the sake of being RF is benefical and would rather an existing format; they think the patent risk of Theora is too high, etc. |
| 16:44 | <erlehmann> | gsnedders, i was more talking about vorbis. |
| 16:44 | <erlehmann> | which is usable almost everywhere except when apple software comes into the picture |
| 16:45 | <gsnedders> | erlehmann: Vorbis is a more interesting question, and less clear why MS/Apple's native frameworks don't support it. |
| 16:47 | <erlehmann> | gsnedders, … says a person working for a company that would take a sizable hit if it had to pay royalties for media decoding, opposed to apple and ms. |
| 16:49 | <erlehmann> | reducing competition is an incentive. |
| 16:52 | <dglazkov> | good morning, Whatwg! |
| 16:53 | <erlehmann> | gsnedders, or wouldn't it? how high are royalties? |
| 16:53 | <gsnedders> | erlehmann: Apple and MS both pay more for licensing than they recieve from them, AFAIK |
| 16:53 | <gsnedders> | erlehmann: Apple certainly does. |
| 16:54 | <gsnedders> | Apple certainly has little financial interest in MPEG-4 being used, and have pushed for everything in MPEG-4 they hold patents on to be RF. |
| 16:55 | <zewt> | as far as I'm concerned, anything MPEG being RF is a bad thing (for the rest of the world) |
| 16:56 | <gsnedders> | zewt: Why? |
| 16:56 | <zewt> | it will slow the adoption and development of truly free codecs |
| 16:56 | <erlehmann> | gsnedders, that is not a point. but 81 million NOK being around 13.5 million US$ may be a point. |
| 16:57 | <gsnedders> | erlehmann: huh? |
| 16:57 | <erlehmann> | apple income is measured in *billions* of dollarites |
| 16:57 | <erlehmann> | gsnedders, i just looked up how big the companies are and figured that licensing media codecs hits a small company more than a big. you tell me if i am correct. |
| 16:58 | <erlehmann> | „big“ as in „operating income“ |
| 16:58 | <gsnedders> | erlehmann: The cost of licensing it to ship encoders and decoders will stay for a while regardless; there's too much existing content out there, and the fact that DVDs and Blu-Ray require the decoders (and encoders, if you want to author content, which bundled software allows) |
| 16:58 | <gsnedders> | erlehmann: Right, yeah. |
| 16:59 | <erlehmann> | if the cost for h.264 stuff is capped at 6.5 million, that it as least the same ballpark. scary. |
| 17:00 | <gsnedders> | The licensing fees aren't a major issue to Apple, but nor is the income they get at all notable. The only financal reasons not to ship more codecs is developer time and patent risk. |
| 17:00 | <erlehmann> | hahaha, doctor evil http://obamapacman.com/wp-content/uploads/2010/02/Dr-Evil-H.264-5-million-dollars-licensing-myth.jpg |
| 17:01 | <erlehmann> | gsnedders, are you assuming that it is not a strategic benefit to make it harder to enter a market? |
| 17:01 | <erlehmann> | >obamapacman.com |
| 17:01 | <erlehmann> | wat |
| 17:01 | <gsnedders> | erlehmann: Which markert? |
| 17:01 | <erlehmann> | harry potter. OBAMA. |
| 17:01 | <gsnedders> | *market |
| 17:02 | <zewt> | gsnedders: it's not hard to contrive other possible financial reasons (whether they're actual considerations or not, only they know) |
| 17:02 | <gsnedders> | Practically, I can't think of any market for which it is a strategic benefit. |
| 17:02 | <erlehmann> | gsnedders, any market. if company A can afford to pay for patents more easily than company B, a competitor, an open standard may not be in the best short-term-interest of the shareholders of company A. |
| 17:02 | <jgraham> | gsnedders: You seem to be missing the point. Irrespective of whether Apple profits directly from licensing fees, requiring browser implementors to support h.264 would be like regressive taxation |
| 17:03 | <jgraham> | In that it would disproportionately affect the poorer players |
| 17:03 | <zewt> | for example, everyone using codecs that cost money could increase the cost--slightly--of creating competing phones |
| 17:03 | <gsnedders> | jgraham: But Apple practically isn't competing with other browser vendors, esp. on iOS. |
| 17:03 | <jgraham> | gsnedders: Huh?! |
| 17:03 | <erlehmann> | gsnedders, what? apple is hindering them for the benefit of its own ecosystem. see the crippling of the audio element API. |
| 17:04 | <jgraham> | I agree that they are trying to have an unlevel playing field |
| 17:04 | <erlehmann> | which is a strategic benefit. gsnedders, i do not see where you are going here. |
| 17:04 | <jgraham> | But they clearly compete with mini on iOS and with other platforms on mobile |
| 17:04 | <gsnedders> | erlehmann: I'd argue that was not wanting the web platform competing with native applications, not a fear about browser marketshare per-se. |
| 17:06 | <gsnedders> | jgraham: And Mini is going for a sufficently different segment of the market when it comes to video support, for example, that it isn't really competition in this context. |
| 17:08 | <gsnedders> | Basically, my point is that for iOS/iPod the market is so full of competitors that already support the same formats (excluding Apple's DRM) that they have no competitive advantage there, as allowing more competitors into the market likely would not be a massive threat to their marketshare; on the desktop it possibly makes F/OSS OSes more plausible, but most users there already install the patent-encumbered codecs anyway, it doesn't give them a comp |
| 17:34 | <hsivonen> | I wonder when Opera is going to have the compute power to do video transcodes on the Mini servers |
| 17:35 | <gsnedders> | hsivonen: A few customers have video transcoding done for custom Mini-based products, FWIW |
| 17:36 | gsnedders | wonders what the average screen resolution of Mini users is |
| 18:06 | <jgraham> | gsnedders: I entirely disagree with the notion that Mini doesn't compete with Mobile Safari. |
| 18:07 | <gsnedders> | jgraham: It does in general. It doesn't compete for people wanting to view YouTube, for example. |
| 18:07 | <gsnedders> | That's all I mean. |
| 18:08 | <gsnedders> | It doesn't compete because it doesn't support the one prerequisite thing: video support. |
| 18:24 | <jgraham> | gsnedders: do you think that is more or less likely to change if usable video implies paying tens of millions of NOK a year to MPEG-LA? |
| 18:26 | <gsnedders> | jgraham: No real change. |
| 19:08 | <erlehmann> | jgraham, lol. |
| 19:08 | <erlehmann> | tens of millions of NOK sounds like EVE Online |
| 20:13 | <annevk> | http://www.nytimes.com/2012/01/02/opinion/krugman-nobody-understands-debt.html "But it also revealed something else: when people in D.C. talk about deficits and debt, by and large they have no idea what they’re talking about — and the people who talk the most understand the least." |
| 20:13 | <annevk> | sounds like your average standards meeting |
| 20:57 | <AryehGregor> | s/in D\.C\. //;s/deficits and debt/anything/ |
| 20:58 | <annevk> | so the writer of that article has @nytimeskrugman as twitter account, but has not posted said article there :/ |
| 20:58 | <annevk> | I've been spending about five minutes trying to research the most appropriate tweet to retweet |
| 20:58 | <TabAtkins> | AryehGregor: What are you doing for Moz now? |
| 20:59 | <annevk> | (@nytimes has not posted it either as far as I can tell) |
| 20:59 | <AryehGregor> | TabAtkins, right this very second, I'm trying to figure out where I'm supposed to call for a one-on-one chat with someone. |
| 20:59 | AryehGregor | is about to just take a guess |
| 20:59 | <AryehGregor> | In general, I'm working on a bunch of stuff, starting with tests for CSS Transforms. |
| 21:16 | <TabAtkins> | annevk: Who's taken over MQ? |
| 21:19 | <jgraham> | Oh, media queries, not mercurial queues |
| 21:19 | <annevk> | Florian I think |
| 21:19 | <annevk> | and Sylvain |
| 21:19 | <TabAtkins> | Thanks! |
| 21:30 | <Yuhong> | I like to mention how IE8 don't support 10 years old web technology: |
| 21:30 | <Yuhong> | http://news.ycombinator.com/item?id=3420948 |
| 22:44 | <ojan> | Hixie, heycam|away: I'm trying to figure out what the resolution to https://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 is. |
| 22:44 | <ojan> | that whole discussion is way over my head |
| 22:45 | <ojan> | I'm just trying to figure out what the resolution is for the sake of fixing http://code.google.com/p/chromium/issues/detail?id=80591 |
| 23:09 | <heycam> | ojan, the upshot is that the var statement will create a new (unconfigurable) own property on window, with value undefined, that shadows the named property |
| 23:11 | <heycam> | ojan, that's due to the use of [ReplaceableNamedProperties] on the Window interface, and the order of resolution of named properties vs own and prototype properties in http://dev.w3.org/2006/webapi/WebIDL/#getownproperty |
| 23:12 | <heycam> | ojan, also in the ecmascript spec it's defined that var statements in global code do a Object.defineProperty(globalObject, varName, { configurable: false, value: undefined }) |
| 23:16 | <ojan> | heycam: ok, so <div id=foo></div><script>var foo; alert(foo);</script> should alert undefined? |
| 23:16 | <heycam> | ojan, yes |
| 23:16 | <ojan> | heycam: great. i'll file the webkit bug. |
| 23:16 | <ojan> | heycam: thx |
| 23:16 | <heycam> | ojan, actually let me just confirm one thing first |
| 23:17 | <heycam> | ojan, ah maybe that is not the case, but I think that is the preferred behaviour |
| 23:18 | <heycam> | ojan, I think I might need to confirm some things with the ES group, since I'm having trouble understanding some aspects of the spec wrt variable declarations |
| 23:19 | heycam | will mail public-script-coord and cc es-discuss |
| 23:20 | <ojan> | heycam: thx. i would definitely like that to be the end result |
| 23:20 | <ojan> | heycam: webkit is willing to change...we just want the behavior clearly specced to avoid changing multiple times |
| 23:20 | <heycam> | ojan, sure |
| 23:20 | <heycam> | I'll CC you on the mail |
| 23:21 | <ojan> | heycam: the current webkit behavior is clearly suboptimal |
