From branstrom at gmail.com Sun Sep 3 11:51:51 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Sun, 3 Sep 2006 13:51:51 +0200 Subject: [sIFR3-dev] IE Message-ID: <22410ce30609030451h3ad464e5ic84b338f5b30af06@mail.gmail.com> I can't get IE to work with nightly r121. The demo is OK but my testing pagedoesn't work. I keep getting this error message . -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at novemberborn.net Tue Sep 5 17:47:50 2006 From: mark at novemberborn.net (Mark Wubben) Date: Tue, 5 Sep 2006 19:47:50 +0200 Subject: [sIFR3-dev] IE In-Reply-To: <22410ce30609030451h3ad464e5ic84b338f5b30af06@mail.gmail.com> References: <22410ce30609030451h3ad464e5ic84b338f5b30af06@mail.gmail.com> Message-ID: On Sep 3, 2006, at 1:51 PM, Fredrik Br?nstr?m wrote: > I can't get IE to work with nightly r121. The demo is OK but my > testing page doesn't work. I've seen that problem before, you probably found it in a different setting. I'll look into it. -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Tue Sep 5 17:49:10 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Tue, 5 Sep 2006 19:49:10 +0200 Subject: [sIFR3-dev] IE In-Reply-To: References: <22410ce30609030451h3ad464e5ic84b338f5b30af06@mail.gmail.com> Message-ID: <22410ce30609051049w370c87e8sed47f1251393d62d@mail.gmail.com> Big thanks. On 9/5/06, Mark Wubben wrote: > > On Sep 3, 2006, at 1:51 PM, Fredrik Br?nstr?m wrote: > > > I can't get IE to work with nightly r121. The demo is OK but my > > testing page doesn't work. > > I've seen that problem before, you probably found it in a different > setting. I'll look into it. > > -- > Mark Wubben > http://novemberborn.net/ > > > > -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at novemberborn.net Sun Sep 10 21:02:43 2006 From: mark at novemberborn.net (Mark Wubben) Date: Sun, 10 Sep 2006 23:02:43 +0200 Subject: [sIFR3-dev] About r138 Message-ID: Hey! Some big changes in r138 today. Over the past week I've fixed most of the issues that came up during my stay in the US. r138 should therefore be pretty stable [1]. I've also decided to drop Flash 7 support. According to the Adobe Flash Player census [2] of June this year Flash 8 is above 80% support word-wide. In light of this the effort of maintaining two Flash movies for each font is too much of a burden. Dropping Flash 7 also fixed an issue with URI handling. The infrastructure for supporting different Flash versions remains in place for future compatibility. Full changelog since r121: * Improved CSS support verification * Better URI handling * IE will work again if there's a height property set (in CSS) for a replaced element * DOMContentLoaded implemented for IE and other supporting browsers, calling `sIFR.initialize()` in the is no longer needed * Added debug information, use `sIFR.debug.ua()` and `sIFR.debug.domains()` * Added automatic conversion of string hex colors in the filter configuration to actual hex values, which are required by Flash. * Added option to better control the anti-aliasing used. Now you can change it through the Flash IDE or Options.as * Fixed encoding of '+' character. * Fixed serialization of empty elements. Check it out here: . [1]: That is, assuming my changes did not introduce new features ? I mean bugs [2]: http://www.adobe.com/products/player_census/flashplayer/ version_penetration.html -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Sun Sep 10 22:34:55 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Mon, 11 Sep 2006 00:34:55 +0200 Subject: [sIFR3-dev] About r138 In-Reply-To: References: Message-ID: <22410ce30609101534t5e5256b8k7df5832dd2ffee9c@mail.gmail.com> That's oh so great news. I was going to ask you if you had had any progress on the bug in IE, and here you come with this big update. Although it might be just a tad early to drop Flash 7? I support your decision, still, from 80 to 95% is quite a jump... thus I'm thankful that you're keeping the old roads intact. And I welcome the introduction of DOMContentLoaded - I've been using http://www.cherny.com/webdev/26/domloaded-object-literal-updated for a while, but this new nightly lets me exclude the sIFR call as it handles it like that by default now which is great, you don't see any flicker when loading and it's not "in the way" at all. It feels a bit snappier too than simply calling sIFR.initialize() from Cherny's script, but maybe not. There shouldn't be any difference. Could you look at those old reports I filed where I had problems with controlling the filters, I'm still not getting the same sharp shadows if I'm configuring filters in the replacement call as opposed to setting them in Flash. * Fixed serialization of empty elements. What's that? Serializing empty elements? On 9/10/06, Mark Wubben wrote: > > Hey! Some big changes in r138 today. Over the past week I've fixed > most of the issues that came up during my stay in the US. r138 should > therefore be pretty stable [1]. I've also decided to drop Flash 7 > support. According to the Adobe Flash Player census [2] of June this > year Flash 8 is above 80% support word-wide. In light of this the > effort of maintaining two Flash movies for each font is too much of a > burden. Dropping Flash 7 also fixed an issue with URI handling. The > infrastructure for supporting different Flash versions remains in > place for future compatibility. > > Full changelog since r121: > > * Improved CSS support verification > * Better URI handling > * IE will work again if there's a height property set (in CSS) for a > replaced element > * DOMContentLoaded implemented for IE and other supporting browsers, > calling `sIFR.initialize()` in the is no longer needed > * Added debug information, use `sIFR.debug.ua()` and > `sIFR.debug.domains()` > * Added automatic conversion of string hex colors in the filter > configuration to actual hex values, which are required by Flash. > * Added option to better control the anti-aliasing used. Now you can > change it through the Flash IDE or Options.as > * Fixed encoding of '+' character. > * Fixed serialization of empty elements. > > Check it out here: r138.zip>. > > [1]: That is, assuming my changes did not introduce new features ? I > mean bugs > [2]: http://www.adobe.com/products/player_census/flashplayer/ > version_penetration.html > > -- > Mark Wubben > http://novemberborn.net/ > > > > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From davebytes at comcast.net Mon Sep 11 15:02:36 2006 From: davebytes at comcast.net (David Chait) Date: Mon, 11 Sep 2006 11:02:36 -0400 Subject: [sIFR3-dev] About r138 References: Message-ID: <001e01c6d5b3$57d077a0$6e01a8c0@sixfour> Well, seeing as we're another 10 weeks downt the road, one would hope the gap continues to close. I have to agree, I'm not big on dropping 'coverage' by 10%, but if it gives us big gains in stability... well... that's a tough argument. More importantly to the 'community' will be getting the 'SWF Fonts' of the world 'upgraded' from current format (Flash 6?) to the Flash 8 format.. We need some automated tools to aid that effort. I mean, we should pick two or three 'starter' fonts from each family type, and hand convert those asap so users sans tools have something to work with. Keep up the great work Mark! I'm looking forward to getting some free cycles to get CG-FlashyTitles v3 updated to your latest rev, and continue to improve my own usability and features. -d | Date: Sun, 10 Sep 2006 23:02:43 +0200 | From: Mark Wubben | Subject: [sIFR3-dev] About r138 | To: sifr3-dev at lists.novemberborn.net | Message-ID: | Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; | format=flowed | | Hey! Some big changes in r138 today. Over the past week I've fixed | most of the issues that came up during my stay in the US. r138 should | therefore be pretty stable [1]. I've also decided to drop Flash 7 | support. According to the Adobe Flash Player census [2] of June this | year Flash 8 is above 80% support word-wide. In light of this the | effort of maintaining two Flash movies for each font is too much of a | burden. Dropping Flash 7 also fixed an issue with URI handling. The | infrastructure for supporting different Flash versions remains in | place for future compatibility. From mark at novemberborn.net Mon Sep 11 17:42:18 2006 From: mark at novemberborn.net (Mark Wubben) Date: Mon, 11 Sep 2006 19:42:18 +0200 Subject: [sIFR3-dev] About r138 In-Reply-To: <22410ce30609101534t5e5256b8k7df5832dd2ffee9c@mail.gmail.com> References: <22410ce30609101534t5e5256b8k7df5832dd2ffee9c@mail.gmail.com> Message-ID: <307A1BB0-47CB-4980-B227-66F731A497C5@novemberborn.net> On Sep 11, 2006, at 12:34 AM, Fredrik Br?nstr?m wrote: > Could you look at those old reports I filed where I had problems with > controlling the filters, I'm still not getting the same sharp > shadows if I'm > configuring filters in the replacement call as opposed to setting > them in > Flash. > I will. > * Fixed serialization of empty elements. > What's that? Serializing empty elements? > Well, if you had something like
in your HTML, it would become
. Probably not very important, but I fixed it anyway :) -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Mon Sep 11 17:49:15 2006 From: mark at novemberborn.net (Mark Wubben) Date: Mon, 11 Sep 2006 19:49:15 +0200 Subject: [sIFR3-dev] About r138 In-Reply-To: <001e01c6d5b3$57d077a0$6e01a8c0@sixfour> References: <001e01c6d5b3$57d077a0$6e01a8c0@sixfour> Message-ID: <5B72877F-178F-460F-8722-C566A99ECF3B@novemberborn.net> On Sep 11, 2006, at 5:02 PM, David Chait wrote: > Well, seeing as we're another 10 weeks downt the road, one would > hope the > gap continues to close. Well, those are about 10 weeks in which I were too busy to actually > I have to agree, I'm not big on dropping 'coverage' > by 10%, but if it gives us big gains in stability... well... that's > a tough > argument. I feel that Flash 7 will be phased out in the next few months, increasing the market share of Flash 8. (I mean, it's been three months since that latest census report). It also makes things easier for users by not having to export two Flash movies ? which also requires commenting out a line in Options.as before you can export to Flash 7. Apologies for only discussing with Mike before I removed the feature. > > More importantly to the 'community' will be getting the 'SWF Fonts' > of the > world 'upgraded' from current format (Flash 6?) to the Flash 8 > format.. We > need some automated tools to aid that effort. I mean, we should > pick two or > three 'starter' fonts from each family type, and hand convert those > asap so > users sans tools have something to work with. You mean provide a good basis of fonts? Perhaps sites like should update? > Keep up the great work Mark! I'm looking forward to getting some free > cycles to get CG-FlashyTitles v3 updated to your latest rev, and > continue to > improve my own usability and features. Yay! -- Mark Wubben http://novemberborn.net/ From davebytes at comcast.net Mon Sep 11 21:51:03 2006 From: davebytes at comcast.net (David Chait) Date: Mon, 11 Sep 2006 17:51:03 -0400 Subject: [sIFR3-dev] About r138 References: <001e01c6d5b3$57d077a0$6e01a8c0@sixfour> <5B72877F-178F-460F-8722-C566A99ECF3B@novemberborn.net> Message-ID: <002d01c6d5ec$60fefe80$6e01a8c0@sixfour> I agree with the developer ease-of-use, and deployment ease, just unsure how it'll impact website visitors (in terms of % not seeing the desired result. ;) ). Yes, we need at least a starter 'set', and getting some of the sifr-related sites updated would be good. Note that many of the sifr font sites got the SWF fonts from other locations, not all compile them directly. Thus the need for some tools to help expedite the availability of sifr3 fonts. Oh, and to bring up an old point, I don't know where/how you do it, but would be good if there was a way to internally tag the 'version' of the SWF font file, so that an old font throws an error/log when in some kind of debug mode (so that site-builders can easily detect 'old' fonts...). -d ----- Original Message ----- From: "Mark Wubben" I feel that Flash 7 will be phased out in the next few months, increasing the market share of Flash 8. (I mean, it's been three months since that latest census report). It also makes things easier for users by not having to export two Flash movies ? which also requires commenting out a line in Options.as before you can export to Flash 7. Apologies for only discussing with Mike before I removed the feature. > > More importantly to the 'community' will be getting the 'SWF Fonts' > of the > world 'upgraded' from current format (Flash 6?) to the Flash 8 > format.. We > need some automated tools to aid that effort. I mean, we should > pick two or > three 'starter' fonts from each family type, and hand convert those > asap so > users sans tools have something to work with. You mean provide a good basis of fonts? Perhaps sites like should update? From amclin at kaadesigngroup.com Tue Sep 12 01:30:13 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Mon, 11 Sep 2006 18:30:13 -0700 Subject: [sIFR3-dev] r138, IE7, and absolutely positioned elements Message-ID: <45060DA5.40504@kaadesigngroup.com> IE7 (and I think IE6 as well) seems to through a fit if the selector being replaced has been absolutely positioned. This was a problem in earlier versions of sIFR as well, but I just didn't figure it out until r138. My solution for now is to throw things inside a inside the absolutely positioned element, and replace that instead. Kludgy, but it works. Firefox 1.5 (and perhaps other browsers) don't have this problem. -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From amclin at kaadesigngroup.com Tue Sep 12 01:45:48 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Mon, 11 Sep 2006 18:45:48 -0700 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text In-Reply-To: <22D75C5B-CD00-45EB-BCB0-5E9762CB7DA5@novemberborn.net> References: <448F3CAC.9030402@kaadesigngroup.com> <5D53CBD3-9D24-4BF1-9903-60E49E38A650@novemberborn.net> <22D75C5B-CD00-45EB-BCB0-5E9762CB7DA5@novemberborn.net> Message-ID: <4506114C.5050402@kaadesigngroup.com> Sorry it's taken so long for me to look into this again (the website went on hold). This seems to work, but not in IE (yay IE!), In IE it causes the non-breaking space character   to be ignored. Example, the address footer on this site: http://susanreddick.development.kaadesigngroup.com/ I'm using   to insert a couple of spaces between the address, the phone, and the fax.... works fine obviously in HTML, and works in Firefox using the config setting you added, but appears in IE to toss out the non-breaking spaces alltogether. -Anthony Mark Wubben wrote: > On Jun 14, 2006, at 2:07 AM, Mark Wubben wrote: >> I'll add an option to preserve all single spaces, though. > > I've added this option in r109 in the nightlies. It replaces all > whitespace characters by a no-breaking space in the Flash text. To > enable, set `sIFR.preserveSingleWhitespace = true;`. > > -- > Mark Wubben > http://novemberborn.net/ > > > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 13 21:45:27 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 13 Sep 2006 23:45:27 +0200 Subject: [sIFR3-dev] r138, IE7, and absolutely positioned elements In-Reply-To: <45060DA5.40504@kaadesigngroup.com> References: <45060DA5.40504@kaadesigngroup.com> Message-ID: On Sep 12, 2006, at 3:30 AM, Anthony McLin wrote: > IE7 (and I think IE6 as well) seems to through a fit if the selector > being replaced has been absolutely positioned. This was a problem in > earlier versions of sIFR as well, but I just didn't figure it out > until > r138. Let me guess, three X's below each other? Sounds like the usual, I'll get it fixed. -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Wed Sep 13 21:47:55 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 13 Sep 2006 23:47:55 +0200 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text In-Reply-To: <4506114C.5050402@kaadesigngroup.com> References: <448F3CAC.9030402@kaadesigngroup.com> <5D53CBD3-9D24-4BF1-9903-60E49E38A650@novemberborn.net> <22D75C5B-CD00-45EB-BCB0-5E9762CB7DA5@novemberborn.net> <4506114C.5050402@kaadesigngroup.com> Message-ID: <88B88778-9618-4FAE-A6BD-7AF4F40FC15B@novemberborn.net> On Sep 12, 2006, at 3:45 AM, Anthony McLin wrote: > This seems to work, but not in IE (yay IE!), In IE it causes the > non-breaking space character   to be ignored. Yeah, it turns out there's a bug in Flash which means the non- breaking space character is not actually exported into the Flash movies (the actual glyph is just not there). Until Adobe fixes this, well, no way to actually use it. -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Wed Sep 13 21:49:41 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Wed, 13 Sep 2006 23:49:41 +0200 Subject: [sIFR3-dev] r138, IE7, and absolutely positioned elements In-Reply-To: References: <45060DA5.40504@kaadesigngroup.com> Message-ID: <22410ce30609131449g7373b1afif8362d12feaceb05@mail.gmail.com> Yeah, that's what I was seeing at some point too. A bit peculiar... We don't want our visitors to think they've ended up where they don't belong, so please fix that ;) On 9/13/06, Mark Wubben wrote: > > On Sep 12, 2006, at 3:30 AM, Anthony McLin wrote: > > > IE7 (and I think IE6 as well) seems to through a fit if the selector > > being replaced has been absolutely positioned. This was a problem in > > earlier versions of sIFR as well, but I just didn't figure it out > > until > > r138. > > Let me guess, three X's below each other? Sounds like the usual, I'll > get it fixed. > > -- > Mark Wubben > http://novemberborn.net/ > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at novemberborn.net Wed Sep 13 21:53:44 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 13 Sep 2006 23:53:44 +0200 Subject: [sIFR3-dev] r138, IE7, and absolutely positioned elements In-Reply-To: <22410ce30609131449g7373b1afif8362d12feaceb05@mail.gmail.com> References: <45060DA5.40504@kaadesigngroup.com> <22410ce30609131449g7373b1afif8362d12feaceb05@mail.gmail.com> Message-ID: <042A04A3-4352-4AD7-9FF8-4450B56D8316@novemberborn.net> On Sep 13, 2006, at 11:49 PM, Fredrik Br?nstr?m wrote: > Yeah, that's what I was seeing at some point too. A bit peculiar... > We don't > want our visitors to think they've ended up where they don't > belong, so > please fix that ;) What's wrong with the City of Amsterdam logo? ;-) -- Mark Wubben http://novemberborn.net/ From davebytes at comcast.net Thu Sep 14 14:39:46 2006 From: davebytes at comcast.net (David Chait) Date: Thu, 14 Sep 2006 10:39:46 -0400 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text References: Message-ID: <003a01c6d80b$a0c06100$0100000a@sixfour> I for one hate relying on the media giant to fix things. ;) Two questions off of this (one related, one sort of related): 1. Can't you translate the nbsp to a 'normal' space when converting the string to the embedded sifr? (i.e., is the nbsp being used to actually prevent break, or because of some other translation in html?) if it's to prevent a break, well, yeah, you need the real glyph so that Flash formats it properly... 2. Is there a way to tell Flash to embed an ENTIRE font into a movie? Say you're working with an asian/multibyte typeface, with thousands of glyphs. Is there a way to tell flash you want every glyph in a given TT font exported, rather than just a selected 'string worth' of text? -d On Sep 12, 2006, Mark Wubben wrote: | On Sep 12, 2006, at 3:45 AM, Anthony McLin wrote: | > This seems to work, but not in IE (yay IE!), In IE it causes the | > non-breaking space character   to be ignored. | | Yeah, it turns out there's a bug in Flash which means the non- | breaking space character is not actually exported into the Flash | movies (the actual glyph is just not there). Until Adobe fixes this, | well, no way to actually use it. From amclin at kaadesigngroup.com Thu Sep 14 16:05:17 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Thu, 14 Sep 2006 09:05:17 -0700 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text In-Reply-To: <003a01c6d80b$a0c06100$0100000a@sixfour> References: <003a01c6d80b$a0c06100$0100000a@sixfour> Message-ID: <45097DBD.2010907@kaadesigngroup.com> For #2, look at the embedding options for the block of text (it's one of the buttons in the properties panel). You can specify a lot of things, including all the glyphs in the font. David Chait wrote: > I for one hate relying on the media giant to fix things. ;) > > Two questions off of this (one related, one sort of related): > 1. Can't you translate the nbsp to a 'normal' space when converting the > string to the embedded sifr? (i.e., is the nbsp being used to actually > prevent break, or because of some other translation in html?) if it's to > prevent a break, well, yeah, you need the real glyph so that Flash formats > it properly... > 2. Is there a way to tell Flash to embed an ENTIRE font into a movie? Say > you're working with an asian/multibyte typeface, with thousands of glyphs. > Is there a way to tell flash you want every glyph in a given TT font > exported, rather than just a selected 'string worth' of text? > > -d > > On Sep 12, 2006, Mark Wubben wrote: > | On Sep 12, 2006, at 3:45 AM, Anthony McLin wrote: > | > This seems to work, but not in IE (yay IE!), In IE it causes the > | > non-breaking space character   to be ignored. > | > | Yeah, it turns out there's a bug in Flash which means the non- > | breaking space character is not actually exported into the Flash > | movies (the actual glyph is just not there). Until Adobe fixes this, > | well, no way to actually use it. > > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From arsart at gmail.com Thu Sep 14 19:00:42 2006 From: arsart at gmail.com (Ars Art) Date: Thu, 14 Sep 2006 23:00:42 +0400 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text In-Reply-To: <45097DBD.2010907@kaadesigngroup.com> References: <003a01c6d80b$a0c06100$0100000a@sixfour> <45097DBD.2010907@kaadesigngroup.com> Message-ID: And for #1 you can easily add Space special character to the manual adding string inside embeding properties. The space character can be copied through Character map. On 14/09/06, Anthony McLin wrote: > For #2, look at the embedding options for the block of text (it's one of > the buttons in the properties panel). You can specify a lot of things, > including all the glyphs in the font. > > > David Chait wrote: > > I for one hate relying on the media giant to fix things. ;) > > > > Two questions off of this (one related, one sort of related): > > 1. Can't you translate the nbsp to a 'normal' space when converting the > > string to the embedded sifr? (i.e., is the nbsp being used to actually > > prevent break, or because of some other translation in html?) if it's to > > prevent a break, well, yeah, you need the real glyph so that Flash formats > > it properly... > > 2. Is there a way to tell Flash to embed an ENTIRE font into a movie? Say > > you're working with an asian/multibyte typeface, with thousands of glyphs. > > Is there a way to tell flash you want every glyph in a given TT font > > exported, rather than just a selected 'string worth' of text? > > > > -d > > > > On Sep 12, 2006, Mark Wubben wrote: > > | On Sep 12, 2006, at 3:45 AM, Anthony McLin wrote: > > | > This seems to work, but not in IE (yay IE!), In IE it causes the > > | > non-breaking space character   to be ignored. > > | > > | Yeah, it turns out there's a bug in Flash which means the non- > > | breaking space character is not actually exported into the Flash > > | movies (the actual glyph is just not there). Until Adobe fixes this, > > | well, no way to actually use it. > > > > _______________________________________________ > > sifr3-dev mailing list > > sifr3-dev at lists.novemberborn.net > > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > > > > > > > -- > Anthony McLin > Senior Web Developer > amclin at kaadesigngroup.com > T 310.821.1400 ext. 266 > F 310.821.1440 > > KAA Design Group, Inc. > 4201 Redwood Avenue > Los Angeles, CA 90066 > > ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS > http://www.kaadesigngroup.com > > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > -- http://designcollector.ru Creativity Database From mark at novemberborn.net Thu Sep 14 22:07:04 2006 From: mark at novemberborn.net (Mark Wubben) Date: Fri, 15 Sep 2006 00:07:04 +0200 Subject: [sIFR3-dev] non-breaking spaces in sIFR replaced text In-Reply-To: <003a01c6d80b$a0c06100$0100000a@sixfour> References: <003a01c6d80b$a0c06100$0100000a@sixfour> Message-ID: On Sep 14, 2006, at 4:39 PM, David Chait wrote: > Two questions off of this (one related, one sort of related): > 1. Can't you translate the nbsp to a 'normal' space when converting > the > string to the embedded sifr? (i.e., is the nbsp being used to > actually > prevent break, or because of some other translation in html?) if > it's to > prevent a break, well, yeah, you need the real glyph so that Flash > formats > it properly... This is what happens already. > 2. Is there a way to tell Flash to embed an ENTIRE font into a > movie? Say > you're working with an asian/multibyte typeface, with thousands of > glyphs. > Is there a way to tell flash you want every glyph in a given TT font > exported, rather than just a selected 'string worth' of text? Yes. However, turns out that the nbsp glyph just isn't being exported. I found a config file to change it, but that didn't help. More at . -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Tue Sep 19 15:06:55 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Tue, 19 Sep 2006 17:06:55 +0200 Subject: [sIFR3-dev] moo.sIFR Message-ID: <22410ce30609190806r586dfdd5tdb925e8f2c1c8388@mail.gmail.com> I just wanted to let you know about a little project of mine. As I often use or plan to use sIFR on websites that also require mootools(or its predecessors, but I'm upgrading most now) for one thing or another, and where I use DomLoaded instead of window.onload, I've started to look at sIFR's code and see how I can optimize it by removing stuff that is already done by these two. DomLoaded only does one thing - load the whole thing. So I started by removing the registerEvents stuff. I removed parseSelector and replaced it with a simple call to $S(selector), and I'll continue with more adaptations. I think I'll write a Ruby script to automate it. At this stage I've gotten the size down on the sifr.js about 7 KB, so it's a few deciseconds faster to load, which I think is great news :) -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at novemberborn.net Tue Sep 19 15:32:32 2006 From: mark at novemberborn.net (Mark Wubben) Date: Tue, 19 Sep 2006 17:32:32 +0200 Subject: [sIFR3-dev] moo.sIFR In-Reply-To: <22410ce30609190806r586dfdd5tdb925e8f2c1c8388@mail.gmail.com> References: <22410ce30609190806r586dfdd5tdb925e8f2c1c8388@mail.gmail.com> Message-ID: Good stuff. sIFR is designed to be completely stand-alone, which means that if you use a JavaScript framework / toolkit there may be some duplication. This is definitely something to be optimized through a pre-compiler script. Some questions, though: Did you replace all occurrences of 'parseSelector' with '$S', or did you point the parseSelector variable to the other function? The event handling is especially tricky, there is a lot of fine- tuning for different browsers and HTML/XHTML modes. You'll want to be careful not to change the semantics here. Also, sIFR code is not compressed yet, so that 7 KB will become less when the release is there ;-) On Sep 19, 2006, at 5:06 PM, Fredrik Br?nstr?m wrote: > I just wanted to let you know about a little project of mine. As I > often use > or plan to use sIFR on websites that also require > mootools(or its predecessors, but I'm upgrading > most now) for one thing or another, > and where I use DomLoaded instead of window.onload, I've started to > look at > sIFR's code and see how I can optimize it by removing stuff that is > already > done by these two. DomLoaded only does one thing - load the whole > thing. So > I started by removing the registerEvents stuff. > > I removed parseSelector and replaced it with a simple call to $S > (selector), > and I'll continue with more adaptations. I think I'll write a Ruby > script to > automate it. > > At this stage I've gotten the size down on the sifr.js about 7 KB, > so it's a > few deciseconds faster to load, which I think is great news :) > > -- > Fredrik Br?nstr?m > http://fredrik.branstrom.nu > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Tue Sep 19 16:15:52 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Tue, 19 Sep 2006 18:15:52 +0200 Subject: [sIFR3-dev] moo.sIFR In-Reply-To: References: <22410ce30609190806r586dfdd5tdb925e8f2c1c8388@mail.gmail.com> Message-ID: <22410ce30609190915o27e9471ft3b9053c37a888e2f@mail.gmail.com> var nodes = $S(kwargs.selector); - that's it. I zapped parseSelector completely, the whole class or whatyamacallit. I'm compressing whitespace, comments and such with an app I found, so sIFR.js lands at 17 KB compressed right now. mootools is also available at different rates of compression (for the featureset I'm using: 18.4 or 27.2KB - 33 KB uncompressed) so it's pretty slim altogether. I'll look at the innards more closely later. There's probably lots of stuff to do there. On 9/19/06, Mark Wubben wrote: > > Good stuff. sIFR is designed to be completely stand-alone, which > means that if you use a JavaScript framework / toolkit there may be > some duplication. This is definitely something to be optimized > through a pre-compiler script. Some questions, though: > > Did you replace all occurrences of 'parseSelector' with '$S', or did > you point the parseSelector variable to the other function? > > The event handling is especially tricky, there is a lot of fine- > tuning for different browsers and HTML/XHTML modes. You'll want to be > careful not to change the semantics here. > > Also, sIFR code is not compressed yet, so that 7 KB will become less > when the release is there ;-) > > On Sep 19, 2006, at 5:06 PM, Fredrik Br?nstr?m wrote: > > > I just wanted to let you know about a little project of mine. As I > > often use > > or plan to use sIFR on websites that also require > > mootools(or its predecessors, but I'm upgrading > > most now) for one thing or another, > > and where I use DomLoaded instead of window.onload, I've started to > > look at > > sIFR's code and see how I can optimize it by removing stuff that is > > already > > done by these two. DomLoaded only does one thing - load the whole > > thing. So > > I started by removing the registerEvents stuff. > > > > I removed parseSelector and replaced it with a simple call to $S > > (selector), > > and I'll continue with more adaptations. I think I'll write a Ruby > > script to > > automate it. > > > > At this stage I've gotten the size down on the sifr.js about 7 KB, > > so it's a > > few deciseconds faster to load, which I think is great news :) > > > > -- > > Fredrik Br?nstr?m > > http://fredrik.branstrom.nu > > _______________________________________________ > > sifr3-dev mailing list > > sifr3-dev at lists.novemberborn.net > > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev > > -- > Mark Wubben > http://novemberborn.net/ > > > -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at novemberborn.net Tue Sep 19 16:57:47 2006 From: mark at novemberborn.net (Mark Wubben) Date: Tue, 19 Sep 2006 18:57:47 +0200 Subject: [sIFR3-dev] moo.sIFR In-Reply-To: <22410ce30609190915o27e9471ft3b9053c37a888e2f@mail.gmail.com> References: <22410ce30609190806r586dfdd5tdb925e8f2c1c8388@mail.gmail.com> <22410ce30609190915o27e9471ft3b9053c37a888e2f@mail.gmail.com> Message-ID: <588BDA55-B3A3-4DF2-A663-0A1A3E3738D4@novemberborn.net> On Sep 19, 2006, at 6:15 PM, Fredrik Br?nstr?m wrote: > var nodes = $S(kwargs.selector); - that's it. I zapped > parseSelector completely, the whole class or whatyamacallit. Okay. You could also do `parseSelector = $S;` (without the parseSelector code) and you wouldn't have to change the sIFR internals. -- Mark Wubben http://novemberborn.net/ From amclin at kaadesigngroup.com Wed Sep 20 17:33:30 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Wed, 20 Sep 2006 10:33:30 -0700 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... Message-ID: <45117B6A.3080903@kaadesigngroup.com> Apparently there is a glitch with using innerHTML with IE that revolves around a timing issue: http://www.shaftek.org/blog/archives/000212.html I'm running into this with using r138, which unfortunately I cannot verify on any of my machines that have IE, but apparently people running IE6 on WinXP SP2 with all updates are seeing it. I've narrowed it down to being sIFR (which does use a lot of innerHTML) but beyond that I can't troubleshoot further. I'll try replacing r138 with r140, but I don't know if it will help since I can't reliably test this. Any thoughts on resolving this would be greatly appreciated -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 20 17:57:05 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 20 Sep 2006 19:57:05 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <45117B6A.3080903@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> Message-ID: <7875BD88-5B11-4E95-8731-1BB4FA189FAB@novemberborn.net> According to this might happen when the DOM is changed inside of the "onreadystatechange" event. Which, matter of fact, is exactly what happens in sIFR in r138. The workaround is in r142, could you verify? Thanks! On Sep 20, 2006, at 7:33 PM, Anthony McLin wrote: > Apparently there is a glitch with using innerHTML with IE that > revolves > around a timing issue: > > http://www.shaftek.org/blog/archives/000212.html > > > I'm running into this with using r138, which unfortunately I cannot > verify on any of my machines that have IE, but apparently people > running > IE6 on WinXP SP2 with all updates are seeing it. I've narrowed it down > to being sIFR (which does use a lot of innerHTML) but beyond that I > can't troubleshoot further. > > I'll try replacing r138 with r140, but I don't know if it will help > since I can't reliably test this. > > > Any thoughts on resolving this would be greatly appreciated > > -- > Anthony McLin > Senior Web Developer > amclin at kaadesigngroup.com > T 310.821.1400 ext. 266 > F 310.821.1440 > > KAA Design Group, Inc. > 4201 Redwood Avenue > Los Angeles, CA 90066 > > ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS > http://www.kaadesigngroup.com > > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev -- Mark Wubben http://novemberborn.net/ From amclin at kaadesigngroup.com Wed Sep 20 18:04:11 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Wed, 20 Sep 2006 11:04:11 -0700 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <45117B6A.3080903@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> Message-ID: <4511829B.6090404@kaadesigngroup.com> I found a machine that I can reliable reproduce the error on, so that helps. This error does occur with r140 as well. --- I just found a workaround, If I move the sIFR.activate() call outside of my head script and to the end of the document, and drop the sIFR.prefetch(font) call, the error goes away. Probably because it changes the timing of events. This probably should be reflected in the example script, and hopefully a way to preload the swf without causing this problem can be found. -Anthony Anthony McLin wrote: > Apparently there is a glitch with using innerHTML with IE that revolves > around a timing issue: > > http://www.shaftek.org/blog/archives/000212.html > > > I'm running into this with using r138, which unfortunately I cannot > verify on any of my machines that have IE, but apparently people running > IE6 on WinXP SP2 with all updates are seeing it. I've narrowed it down > to being sIFR (which does use a lot of innerHTML) but beyond that I > can't troubleshoot further. > > I'll try replacing r138 with r140, but I don't know if it will help > since I can't reliably test this. > > > Any thoughts on resolving this would be greatly appreciated > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 20 18:06:56 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 20 Sep 2006 20:06:56 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <4511829B.6090404@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> Message-ID: On Sep 20, 2006, at 8:04 PM, Anthony McLin wrote: > I found a machine that I can reliable reproduce the error on, so > that helps. Great news. > This error does occur with r140 as well. Could you test with r142? If it's there as well, then, uhm, let's just say poor me :) > > --- I just found a workaround, > If I move the sIFR.activate() call outside of my head script and to > the > end of the document, and drop the sIFR.prefetch(font) call, the error > goes away. Probably because it changes the timing of events. What if you just drop the pre-fetch? -- Mark Wubben http://novemberborn.net/ From amclin at kaadesigngroup.com Wed Sep 20 18:12:28 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Wed, 20 Sep 2006 11:12:28 -0700 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> Message-ID: <4511848C.3040403@kaadesigngroup.com> r142 still exhibits the problem If I drop the prefetch it does appear to resolve the problem. (I thought I had tried that on r138 and r140, but I could be wrong). -Anthony Mark Wubben wrote: > On Sep 20, 2006, at 8:04 PM, Anthony McLin wrote: >> I found a machine that I can reliable reproduce the error on, so that >> helps. > > Great news. > >> This error does occur with r140 as well. > > Could you test with r142? If it's there as well, then, uhm, let's just > say poor me :) > >> >> --- I just found a workaround, >> If I move the sIFR.activate() call outside of my head script and to the >> end of the document, and drop the sIFR.prefetch(font) call, the error >> goes away. Probably because it changes the timing of events. > > What if you just drop the pre-fetch? > > -- > Mark Wubben > http://novemberborn.net/ > > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 20 18:21:37 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 20 Sep 2006 20:21:37 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <4511848C.3040403@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> Message-ID: <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> On Sep 20, 2006, at 8:12 PM, Anthony McLin wrote: > r142 still exhibits the problem > > If I drop the prefetch it does appear to resolve the problem. (I > thought I had tried that on r138 and r140, but I could be wrong). Okay, that's sort of good news. The pre-fetch is there as a workaround, which means I know need a workaround for a workaround. Some tricks can be used to delay the loading of it, though. I'll be working on some isolated test cases in an attempt to find a solution. I'll leave the workaround from r142 in there though, just in case. -- Mark Wubben http://novemberborn.net/ From amclin at kaadesigngroup.com Wed Sep 20 18:52:59 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Wed, 20 Sep 2006 11:52:59 -0700 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> Message-ID: <45118E0B.20506@kaadesigngroup.com> Thanks for looking into this! Mark Wubben wrote: > On Sep 20, 2006, at 8:12 PM, Anthony McLin wrote: > >> r142 still exhibits the problem >> >> If I drop the prefetch it does appear to resolve the problem. (I >> thought I had tried that on r138 and r140, but I could be wrong). > > Okay, that's sort of good news. The pre-fetch is there as a > workaround, which means I know need a workaround for a workaround. > Some tricks can be used to delay the loading of it, though. I'll be > working on some isolated test cases in an attempt to find a solution. > > I'll leave the workaround from r142 in there though, just in case. > > -- > Mark Wubben > http://novemberborn.net/ > > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 20 19:40:24 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 20 Sep 2006 21:40:24 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <45118E0B.20506@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> <45118E0B.20506@kaadesigngroup.com> Message-ID: On Sep 20, 2006, at 8:52 PM, Anthony McLin wrote: > Thanks for looking into this! Could you look at the tests at and let me know which work and which don't? -- Mark Wubben http://novemberborn.net/ From amclin at kaadesigngroup.com Wed Sep 20 19:54:48 2006 From: amclin at kaadesigngroup.com (Anthony McLin) Date: Wed, 20 Sep 2006 12:54:48 -0700 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> <45118E0B.20506@kaadesigngroup.com> Message-ID: <45119C88.2000602@kaadesigngroup.com> All 4 tests appear to be working on the machine configuration that had been exhibiting errors.... but then again it doesn't appear you are doing any replacement on those pages, or perhaps the page is loading fast enough that it's not an issue? Mark Wubben wrote: > On Sep 20, 2006, at 8:52 PM, Anthony McLin wrote: > >> Thanks for looking into this! > > Could you look at the tests at > > and let me know which work and which don't? > > > -- > Mark Wubben > http://novemberborn.net/ > > > -- Anthony McLin Senior Web Developer amclin at kaadesigngroup.com T 310.821.1400 ext. 266 F 310.821.1440 KAA Design Group, Inc. 4201 Redwood Avenue Los Angeles, CA 90066 ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS http://www.kaadesigngroup.com From mark at novemberborn.net Wed Sep 20 21:49:40 2006 From: mark at novemberborn.net (Mark Wubben) Date: Wed, 20 Sep 2006 23:49:40 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <45119C88.2000602@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> <45118E0B.20506@kaadesigngroup.com> <45119C88.2000602@kaadesigngroup.com> Message-ID: On Sep 20, 2006, at 9:54 PM, Anthony McLin wrote: > All 4 tests appear to be working on the machine configuration that > had been exhibiting errors.... but then again it doesn't appear you > are doing any replacement on those pages, or perhaps the page is > loading fast enough that it's not an issue? It should be doing the pre-fetching which caused trouble before. -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Sat Sep 23 09:42:39 2006 From: mark at novemberborn.net (Mark Wubben) Date: Sat, 23 Sep 2006 11:42:39 +0200 Subject: [sIFR3-dev] Remove compatMode? Message-ID: With Flash 7 out of the picture, is it worthwhile to include backwards compatibility code for Safari 1.0 - 1.2, Netscape 6 and Opera < 7.5? These browsers can't find the current style properties associated with borders and padding, which is needed for proper calculation of the element width and height. It's only a handful of lines of code, and disabled by default, but it *would* make the code a bit cleaner and remove the extra, but voluntary, effort of specifying the horizontal and vertical space taken in by padding and borders. What are your thoughts? -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Sat Sep 23 13:00:14 2006 From: mark at novemberborn.net (Mark Wubben) Date: Sat, 23 Sep 2006 15:00:14 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> <45118E0B.20506@kaadesigngroup.com> <45119C88.2000602@kaadesigngroup.com> Message-ID: <3B6F70D6-46BE-4D72-BC0F-3F6C5C47AAB2@novemberborn.net> I've put up a sIFR build which alerts for DOM modifications. Could you let me know after which alert it fails? See here: . Thanks! On Sep 20, 2006, at 11:49 PM, Mark Wubben wrote: > On Sep 20, 2006, at 9:54 PM, Anthony McLin wrote: > >> All 4 tests appear to be working on the machine configuration that >> had been exhibiting errors.... but then again it doesn't appear you >> are doing any replacement on those pages, or perhaps the page is >> loading fast enough that it's not an issue? > > It should be doing the pre-fetching which caused trouble before. > > -- > Mark Wubben > http://novemberborn.net/ > > > _______________________________________________ > sifr3-dev mailing list > sifr3-dev at lists.novemberborn.net > http://lists.novemberborn.net/mailman/listinfo/sifr3-dev -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Mon Sep 25 21:10:00 2006 From: mark at novemberborn.net (Mark Wubben) Date: Mon, 25 Sep 2006 23:10:00 +0200 Subject: [sIFR3-dev] sifr, innerHTML, and of course, IE..... In-Reply-To: <45183F8B.1050503@kaadesigngroup.com> References: <45117B6A.3080903@kaadesigngroup.com> <4511829B.6090404@kaadesigngroup.com> <4511848C.3040403@kaadesigngroup.com> <09A3AD88-EA5E-4590-ADA3-4849EB87279D@novemberborn.net> <45118E0B.20506@kaadesigngroup.com> <45119C88.2000602@kaadesigngroup.com> <3B6F70D6-46BE-4D72-BC0F-3F6C5C47AAB2@novemberborn.net> <4517FA06.3060604@kaadesigngroup.com> <842F7BF8-89EC-43B7-A4F0-BCD90AA89AD0@novemberborn.net> <451814BE.7020301@kaadesigngroup.com> <9691105C-0623-4773-A8B8-7C05CE839100@novemberborn.net> <45181928.2010208@kaadesigngroup.com> <4082AA2F-9FF0-4A2E-A48E-942C258F8873@novemberborn.net> <45183F8B.1050503@kaadesigngroup.com> Message-ID: On Sep 25, 2006, at 10:43 PM, Anthony McLin wrote: > I tested with r148, fails. r147 with the alert statements fails > after "attaching events". Good. I've added some more alerts (same file location), could you again see when it fails? > > -Anthony > > > Mark Wubben wrote: >> On Sep 25, 2006, at 8:00 PM, Anthony McLin wrote: >>> This site still reliably fails on the test rig when I re-enable >>> the preload. It's using r142 >> >> What if you try r148? Or r147 with the alert statements from >> > sifr/sifr.js>? >> >> -- >> Mark Wubben >> http://novemberborn.net/ >> >> >> > > > -- > Anthony McLin > Senior Web Developer > amclin at kaadesigngroup.com > T 310.821.1400 ext. 266 > F 310.821.1440 > > KAA Design Group, Inc. > 4201 Redwood Avenue > Los Angeles, CA 90066 > > ARCHITECTURE | LANDSCAPE | GRAPHICS | INTERIORS > http://www.kaadesigngroup.com > -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Mon Sep 25 21:10:53 2006 From: mark at novemberborn.net (Mark Wubben) Date: Mon, 25 Sep 2006 23:10:53 +0200 Subject: [sIFR3-dev] Lisbon Message-ID: <237388E8-C447-4949-8699-15C27072DD11@novemberborn.net> Hey, I'm going to be in Lisbon from Wednesday - Saturday for SHiFT [1]. If you're in town, let's meet! :) [1]: http://shift.pt/ -- Mark Wubben http://novemberborn.net/ From mark at novemberborn.net Sat Sep 30 15:54:40 2006 From: mark at novemberborn.net (Mark Wubben) Date: Sat, 30 Sep 2006 16:54:40 +0100 Subject: [sIFR3-dev] Remove compatMode? In-Reply-To: <22410ce30609291259m19ca1163q575872791c4668ac@mail.gmail.com> References: <22410ce30609291259m19ca1163q575872791c4668ac@mail.gmail.com> Message-ID: On Sep 29, 2006, at 8:59 PM, Fredrik Br?nstr?m wrote: > How many kilobytes? I won't know until I try :) The real question is if people using these browsers will be using Flash 8. -- Mark Wubben http://novemberborn.net/ From branstrom at gmail.com Sat Sep 30 15:56:06 2006 From: branstrom at gmail.com (=?ISO-8859-1?Q?Fredrik_Br=E4nstr=F6m?=) Date: Sat, 30 Sep 2006 17:56:06 +0200 Subject: [sIFR3-dev] Remove compatMode? In-Reply-To: References: <22410ce30609291259m19ca1163q575872791c4668ac@mail.gmail.com> Message-ID: <22410ce30609300856p5fe8b830qae6ab2f09d890ec1@mail.gmail.com> My vote: remove the old shit. :) On 9/30/06, Mark Wubben wrote: > > On Sep 29, 2006, at 8:59 PM, Fredrik Br?nstr?m wrote: > > > How many kilobytes? > > I won't know until I try :) The real question is if people using > these browsers will be using Flash 8. > > -- > Mark Wubben > http://novemberborn.net/ > > > -- Fredrik Br?nstr?m http://fredrik.branstrom.nu -------------- next part -------------- An HTML attachment was scrubbed... URL: