| 00:01 | <crankharder> | when do I have to add that event, as I understand it the cache is downloadded as soon as it sees the <html> tag. so where/how do I add the event? |
| 00:01 | <crankharder> | Hixie: ^ :) |
| 00:33 | <MikeSmith> | yeah seems like arraybuffer has already joined the hallowed hall of suboptimal platform features we are now stuck with |
| 00:34 | <MikeSmith> | why tc39 didn't make the binary stuff a priority back when is beyond me |
| 00:37 | <jamesr_> | i'm not sure what in particular is wrong with it |
| 00:57 | <crankharder> | how can I track whether a user has approved the applicationCache? |
| 00:57 | <crankharder> | cookie? |
| 01:05 | <MikeSmith> | jamesr_: ask Alex Russell |
| 05:43 | <Hixie> | is there a simple way to find out how many properties an object has, short of enumerating through the object's properties? |
| 05:46 | <Hixie> | shepazu: btw, iirc i wasn't just against svg getting text wrapping. i was (and still am) against the web platform getting text wrapping twice, instead of svg working with html and css to just make the text wrapping we already have work with svg. |
| 05:47 | <Hixie> | i even made proposals for how to make it work |
| 05:51 | <shepazu> | Hixie: iirc, we tried to make the point that SVG text wrapping was not incompatible with CSS text wrapping, and that they could both use the same algorithm… to this day, I don't recall anyone stated clearly what the alleged incompatibilities were… we were (and are) quite willing to make SVG's text wrapping match the CSS model |
| 05:53 | <Hixie> | having seen what happened when xsl "used the same algorithm" as css, or indeed when svg "used css" for units and the mess that made with the 'font' property, i hope you'll understand why i (we) were skeptical... |
| 05:54 | <Hixie> | my point though was just that your tweet seemed to imply obstructionism when it was in fact just a difference in opinion as to how the feature should be implemented |
| 05:54 | <shepazu> | "skeptical" is rather a mild way of putting it… I would characterize it more as "hostile" |
| 05:55 | <Hixie> | well, that was probably more a result of other things going on at the time |
| 05:55 | <Hixie> | e.g. the svg wg blatently ignoring w3c process, etc |
| 05:55 | <Hixie> | water under the bridge, hopefully |
| 06:09 | <shepazu> | Hixie: by "how the feature should be implemented", I'm only able to find a single concrete suggestion from you, which was to remove text-wrapping from SVGT1.2 and replace it with HTML+CSS in a <foreignObject> http://lists.w3.org/Archives/Public/www-svg/2006Mar/0174.html … maybe I'm missing some earlier email |
| 06:09 | <Hixie> | yes, that's what i was talking about |
| 06:10 | <Hixie> | i still think that that's the way to do it (or rather, the way to do it is to have just an html page, and the wrapping done in css via reference to an svg path or other construct) |
| 06:10 | <shepazu> | I don't think most people would consider that "text wrapping in SVG" |
| 06:11 | <Hixie> | i don't think most people think of "svg" as a special thing. it's text wrapping on the web that matters. |
| 06:12 | <shepazu> | I think that most people who use SVG certainly do think of it as different than HTML… they author it with Inkscape or Illustrator |
| 06:12 | <Hixie> | that's just a historical artefact of how svg was developed |
| 06:12 | <Hixie> | svg is just a part of the web platform |
| 06:13 | <Hixie> | it harms us all to consider it a silo |
| 06:13 | <Hixie> | it's a kind of "not invented here" syndrome |
| 06:14 | <shepazu> | it's not a "historical artefact", it's a workflow that hundreds of thousands (possibly millions) of people use (e.g. designers) |
| 06:14 | Hixie | shrugs |
| 06:14 | <Hixie> | ok |
| 06:14 | <Hixie> | i have no interest debating this right now :-) |
| 06:14 | <shepazu> | so, if that is your solution, then yes, reading back through some of the archived emails, I think it was you being obstructionist |
| 06:15 | <shepazu> | well, then we agree on something, because I'm not interested in debating it either :) |
| 06:16 | <Hixie> | i think you are causing massive harm to the web's design by sticking to this silo model |
| 06:16 | <Hixie> | and i think it's disingenous to say that disagreeing with your silo model is obstructionist |
| 06:16 | <Hixie> | but i gotta go. bbl. |
| 06:17 | <shepazu> | I think the evidence speaks for itself that I've tried very hard to find ways for SVG, CSS, and HTML to work smoothly together, forming the FX task force, urging you to allow SVG in HTML, etc. |
| 06:18 | <shepazu> | I even tried to correct the course of the Compound Documents WG, though the harm had already been done there |
| 06:19 | <shepazu> | and your characterizing what I'm saying as a "silo model" is just silly |
| 06:21 | <shepazu> | further, I think you are just saying things "for the record", rather than having a real conversation, so I'm happy to leave it as it stands |
| 06:41 | <MikeSmith> | does gecko have any support for transferable objects yet? |
| 06:41 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects |
| 08:53 | <MikeSmith> | Ms2ger: thanks |
| 08:53 | <Ms2ger> | Np :) |
| 08:53 | <MikeSmith> | I should have searched more carefully |
| 08:53 | <Ms2ger> | Any other bugs you filed? ;) |
| 08:54 | <MikeSmith> | though I guess now if somebody else searches for "mutation observers" before filing a feature bug, they will see that and know |
| 08:54 | <MikeSmith> | Ms2ger: I filed a bug for Transferable objects |
| 08:54 | <MikeSmith> | and .. one more |
| 08:54 | <MikeSmith> | I forget what for |
| 08:54 | <MikeSmith> | lemme look |
| 08:54 | <Ms2ger> | Don't remember a bug for that one |
| 08:55 | <MikeSmith> | btw, do you know if dupes show up in the bug wizard thingey? |
| 08:55 | <MikeSmith> | hmm, probably not I guess |
| 08:56 | <MikeSmith> | anyway, it seems the transferable objects bug was in fact the only other I filed today |
| 08:56 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=720083 |
| 08:57 | <MikeSmith> | oh wait |
| 08:57 | <MikeSmith> | I didn't see the getusermedia one til now |
| 08:57 | <MikeSmith> | so thanks again! |
| 08:58 | <Ms2ger> | :) |
| 11:03 | <hsivonen> | hmm. Wikipedia says Chrome added Theora and H.264 in different releases. |
| 11:03 | <hsivonen> | that's bogus, right? |
| 11:03 | <hsivonen> | also, Wikipedia says the Android browser added Theora in 2.3 and H.264 in 3.0. That's completely bogus, right? |
| 11:04 | <hsivonen> | the truthiness of http://en.wikipedia.org/wiki/HTML5_video#Table is sad |
| 11:11 | <Ms2ger> | +[citation needed] :) |
| 11:13 | <hsivonen> | also, it's sad that Wikipedia considers the WMP gimmick extension to Firefox to be on the same level as things that actually add codec support to IE9 in a way that makes the <video> APIs work |
| 11:15 | <doublec> | hsivonen: I wasn't aware the android browser did Theora - does it really? |
| 11:15 | <hsivonen> | doublec: not that I know |
| 11:15 | doublec | tries |
| 11:15 | <hsivonen> | doublec: see "completely bogus" above |
| 11:16 | <doublec> | hsivonen: nope, it doesn't |
| 11:16 | <doublec> | hsivonen: at least on ice cream sandwich on a nexus S it fails |
| 11:19 | <hsivonen> | Is there any way to map Maxthon versions to Trident versions? Or are they orthogonal? Mathon uses whatever Trident there is? |
| 11:19 | <hsivonen> | s/Mathon/Maxthon/ |
| 11:33 | <hsivonen> | so, according to StatCounter, the usage share of WebM-enabled browser is more than the usage share of H.264-enabled browsers in Europe |
| 11:33 | <hsivonen> | "according to" in the sense of plugging statcounter number into my script that embodies knowledge of which versions support what |
| 11:41 | <hsivonen> | globally even |
| 13:13 | <hsivonen> | gotta step away from the computer to avoid getting stuck in the 386 mode replying to tweets commenting on my WebM math |
| 15:15 | smaug____ | kicks Google hard |
| 15:22 | <gsnedders> | hsivonen: FWIW, I believe *technically* Opera on Linux/FreeBSD does still support H.264 if the system does, it's just the standard codecs are blacklisted (due to stability issues, AIUI). |
| 15:27 | <smaug____> | perhaps other browser vendors should have automatic tool to remove Chrome ads |
| 15:28 | <smaug____> | s/browser vendors/browsers/ |
| 15:29 | gsnedders | might be wrong, though |
| 15:31 | <hsivonen> | gsnedders: foolip said he removed support for that |
| 15:31 | <hsivonen> | I succumbed to 386 and added a FAQ section to my post |
| 16:09 | <hsivonen> | argh. added even more 386 about Chrome (not) dropping h.264 support |
| 16:21 | <hsivonen> | sigh. even at hacker news they speculate without reading the script I provided so that everyone can see what I did |
| 17:12 | <Ms2ger> | Hixie, something like Object.getOwnPropertyNames(obj).length, maybe? |
| 21:00 | <jacobolus> | in a hacker news discussion, I criticized the usefulness of -webkit-cross-fade, saying that just applying alpha transparency to the top image should do the trick. in response someone pasted the text of the spec. as written, it's actually wrong. should I tell someone about that? |
| 21:00 | <jacobolus> | the spec is here http://www.w3.org/TR/2011/WD-css3-images-20110217/#cross-fade-function |
| 21:00 | <jacobolus> | and the bit that's wrong is "Then, the start image has a global alpha applied to it equal to (1-p), the end image has a global alpha applied to it equal to p, and the end image is then composited over the start image with the source-over operation. [[PORTERDUFF]]" |
| 21:05 | <jacobolus> | in particular, compositing the end image (to take Porter–Duff’s example, let’s say picture A) *over* the start image (picture B), we end up with for each pixel–channel (assuming pre-multiplied alpha) is c_O = c_A * 1 + c_B * (1 - alpha_A) |
| 21:07 | <jacobolus> | if the top image is semitransparent, and the bottom image is opaque, what we get as a result is a pixel color linearly interpolated between the bottom pixel and the top pixel at the amount of the opacity of the top image, i.e. a "cross fade" |
| 21:08 | <jacobolus> | but so anyway, where the spec goes wrong is in stating that an alpha should be applied to the bottom image AND THEN the top image should be composited onto it using the PD "over" operation |
| 21:09 | <jacobolus> | the PD over operation already includes applying such an alpha to the bottom image, inherently as part of its function |
| 21:09 | <jacobolus> | so what the spec tells us to do is apply such an alpha multiplier to the bottom image TWICE, which is clearly wrong |
| 21:11 | <jacobolus> | Bringing Porter Duff into this part of the spec at all is unnecessary complexity and likely to lead to confusion. Instead, the spec should stipulate that (in non-premultiplied-alpha terms) the cross fade should straight linearly interpolate between the R, G, B, and A components of the two images |
| 21:11 | <jacobolus> | that would make it do the right thing when the original images themselves are semi-transparent (which is the only use case not adequately served by the simple "set the opacity on the top layer" method) |
| 21:13 | <jacobolus> | in my opinion, the parts of the spec about taking two images of different sizes and cross-fading between them by interpolating between their heights and widths seems like a solution in search of a problem. are there concrete use cases in mind for that? my first suggestion would be to drop the spec altogether, as unnecessary |
| 21:14 | <jacobolus> | TabAtkins: you might find the above few comments useful? ↑ |