A month ago, Google announced that they had improved the way it
indexes Flash files. Has something changed in Google’s search results
in the meantime? Is this change good news for you if you have a Flash
site?
What has changed?
1. Google can now index the textual content in SWF files of all
kinds, including buttons, menus and self-contained Flash websites.
2. Google can also discover URLs that appear in Flash files and
it adds these URLs to the crawling pipeline.
What has not changed?
1. Google still doesn’t recognize the text that appears on
images. FLV files, such as YouTube videos also won’t be indexed
because they don’t contain text.
2. As many Flash websites consist of images and other
multimedia elements, the only text that Google finds on these websites
might be “Loading”, “Please wait” or “Copyright”.
3. Google also cannot execute some JavaScript types. If your
website loads a Flash file via JavaScript, Google might not be able to
find your Flash file.
4. In addition, Google cannot attach content from external
sources that are loaded by Flash files. If your Flash page loads an
HTML or XML file then these files will be treated as separate
documents.
Why is Flash still a problem for search engines?
Flash content and regular HTML pages are fundamentally different.
Just because Google can now index some text from Flash files doesn’t
mean that Flash files are now search engine friendly. Here’s why:
1. It’s hard to divide the text into meaningful sections. Flash
doesn’t use <h1> or <p> tags to separate different sections of text.
It’s hard to tell what’s important and what’s not. Even worse, Flash
designers often break down words into their individual letters to
create “cool” text effects. That means that search engines cannot
index these texts.
2. Usually, the complete content of a website is presented on
the same URL. You cannot link to a special part of a Flash website.
That means that it is also difficult for search engines to find the
relevant section of the Flash site.
3. In addition, this means that Flash websites don’t get good
inbound links to the right pages. Most Flash websites only get links
to their home page.
4. The structure of Flash websites makes it difficult to get
high rankings. Many Flash files are linked from other Flash files and
no other websites link to these internal Flash elements. The lack of
links from other websites makes it very difficult to get high rankings
for these elements.
5. Flash doesn’t use the basic SEO methods. You won’t find
proper link texts, headline tags or even properly optimized title tags
in most Flash sites. That makes it very difficult to get good
rankings.
6. Most Flash content is still not crawlable. As mentioned
above, Google won’t index content in images and it has problems with
JavaScript calls.
What can you do to improve your rankings if you have a Flash site?
If possible, avoid pure Flash websites and use Flash elements only
when needed. If you must use Flash on your website, the following tips
will help you to get better rankings:
Include the text and the links from the Flash file in an HTML
version on the same page.
Use JavaScript and CSS to find out if the website visitor can
parse Flash and then present the CSS DIVs that contain the
corresponding content. Regular website users will see the Flash file,
visitors who cannot parse Flash (for example search engines) will see
the HTML version.
1. Use CSS and create a layer with your regular HTML content
and then position another layer with the Flash content above the HTML
layer so that your website visitors only see the Flash content. Note
that search engines might misinterpret this method as a spamming
attempt.
Use different URLs for different sections of your website. Each
set of content should have its own unique URL.
Flash has not been designed for search engines and it is extremely
difficult to get high rankings with pure Flash sites. Using regular
optimized web pages is the best way to get in Google’s top 10 results.
> Is this change good news for you if you have a Flash
> site?
Its bad news for searchers. I have yet to see a flash site that I have
the patience to wait for it to load. Google is a doing a diservice to
the searcher by not banning flash sites.
>What has changed?
>1. Google can now index the textual content in SWF files of all
>kinds, including buttons, menus and self-contained Flash websites.
Not exactly, Google has made some improvements but can't index text
all content in all SWF files of all kinds and in every case. For
example, content loaded into SWF files dynamically from another
source, isn't indexed at all.
>As mentioned
>above, Google won’t index content in images and it has problems with
>JavaScript calls.
Not exactly, Google supports common JavaScript techniques like those
used for SWFObject and SWFObject2.
>Use JavaScript and CSS to find out if the website visitor can
>parse Flash and then present the CSS DIVs that contain the
>corresponding content.
Wait, you just said Google indexes Flash! By adding corresponding
content to real content in Flash, you've created duplicate content.
Perhaps why Google doesn't recommend techniques like SWFObject.
>Use different URLs for different sections of your website. Each
>set of content should have its own unique URL.
1.) Googlebot ignores #anchors in URLs, which you'll need to forward
the playhead in "the flash file".
2.) By creating a different URL for different pages and copying the
same SWF into each page, you are duplicating content across each page
as well as running the risk of text contents in the SWF found in each
"page" not exactly matching content also see by engines in the code of
"page" where said SWF is housed. Doing this for at all, much less for
an entire "section" of a site complicates things even more....
3.) While duplicate content in Flash may not be penalized, creating
another version for engines only to have it filtered from results,
kind of defeats the purpose? In addition to this other "set" of
content being filtered the technique mentioned also acts to thin
PageRank as well as keyword relevancy from the anchor text of inbound
links.
Either use Flash or don't, either way I'd avoid mixing old and what
some would call risky techniques for optimizing Flash in Google's new
Flash environment. Just my two cents, best of luck to you! :)
> A month ago, Google announced that they had improved the way it
> indexesFlashfiles. Has something changed in Google’s search results
> in the meantime? Is this change good news for you if you have aFlash
> site?
> What has changed?
> 1. Google can now index the textual content in SWF files of all
> kinds, including buttons, menus and self-containedFlashwebsites.
> 2. Google can also discover URLs that appear inFlashfiles and
> it adds these URLs to the crawling pipeline.
> What has not changed?
> 1. Google still doesn’t recognize the text that appears on
> images. FLV files, such as YouTube videos also won’t be indexed
> because they don’t contain text.
> 2. As manyFlashwebsites consist of images and other
> multimedia elements, the only text that Google finds on these websites
> might be “Loading”, “Please wait” or “Copyright”.
> 3. Google also cannot execute some JavaScript types. If your
> website loads aFlashfile via JavaScript, Google might not be able to
> find yourFlashfile.
> 4. In addition, Google cannot attach content from external
> sources that are loaded byFlashfiles. If yourFlashpage loads an
> HTML or XML file then these files will be treated as separate
> documents.
> Why isFlashstill a problem for search engines?
> Flashcontent and regular HTML pages are fundamentally different.
> Just because Google can now index some text fromFlashfiles doesn’t
> mean thatFlashfiles are now search engine friendly. Here’s why:
> 1. It’s hard to divide the text into meaningful sections.Flash
> doesn’t use <h1> or <p> tags to separate different sections of text.
> It’s hard to tell what’s important and what’s not. Even worse,Flash
> designers often break down words into their individual letters to
> create “cool” text effects. That means that search engines cannot
> index these texts.
> 2. Usually, the complete content of a website is presented on
> the same URL. You cannot link to a special part of aFlashwebsite.
> That means that it is also difficult for search engines to find the
> relevant section of theFlashsite.
> 3. In addition, this means thatFlashwebsites don’t get good
> inbound links to the right pages. MostFlashwebsites only get links
> to their home page.
> 4. The structure ofFlashwebsites makes it difficult to get
> high rankings. ManyFlashfiles are linked from otherFlashfiles and
> no other websites link to these internalFlashelements. The lack of
> links from other websites makes it very difficult to get high rankings
> for these elements.
> 5.Flashdoesn’t use the basic SEO methods. You won’t find
> proper link texts, headline tags or even properly optimized title tags
> in mostFlashsites. That makes it very difficult to get good
> rankings.
> 6. MostFlashcontent is still not crawlable. As mentioned
> above, Google won’t index content in images and it has problems with
> JavaScript calls.
> What can you do to improve your rankings if you have aFlashsite?
> If possible, avoid pureFlashwebsites and useFlashelements only
> when needed. If you must useFlashon your website, the following tips
> will help you to get better rankings:
> Include the text and the links from theFlashfile in an HTML
> version on the same page.
> Use JavaScript and CSS to find out if the website visitor can
> parseFlashand then present the CSS DIVs that contain the
> corresponding content. Regular website users will see theFlashfile,
> visitors who cannot parseFlash(for example search engines) will see
> the HTML version.
> 1. Use CSS and create a layer with your regular HTML content
> and then position another layer with theFlashcontent above the HTML
> layer so that your website visitors only see theFlashcontent. Note
> that search engines might misinterpret this method as a spamming
> attempt.
> Use different URLs for different sections of your website. Each
> set of content should have its own unique URL.
> Flashhas not been designed for search engines and it is extremely
> difficult to get high rankings with pureFlashsites. Using regular
> optimized web pages is the best way to get in Google’s top 10 results.
Wow! This is one loaded thread. Hat tips to Beussery for dragging me
back into the group.
Changes:
1. Beussery already mentioned this, but "textual elements of all
kinds" is ambiguous. Vector graphics that create human-readable text,
dynamically-loaded textual elements, and other obfuscated textual
elements probably aren't going to be crawled. If you're counting on
Google crawling your textual elements, you may want to play it safe by
making sure that they're elements you can type and edit in the program
you're using to create your flash file, that the elements are actually
stored in the same file you're referencing in the HTML page, and that
the text is not stored in a non-machine-readable format like a vector
graphic.
2. From what I've seen on search results so far, it is generally true
that Google can grab URLs from Flash files and insert them into the
crawling pipeline. However, this leads to two additional concerns:
(a) strange text processing on URLs may not be properly handled by the
Googlebot, and (b) linking data will likely not carry as much nuance
if it comes from the middle of a Flash file as from an HTML page.
After all, Google has been looking at HTML links for a VERY long time--
links in Flash, far less long.
What hasn't changed:
1. Yes.
2. Yes.
3. Right: Some javascript, Google loads up fine. Some it doesn't.
The rule of thumb is that the more complex or uncommon the JS, the
less the chance that Google will find your Flash URL. However, I'll
state again, that's just a rule of thumb. If you want your flash
content indexed, have it be a part of a file that's directly
referenced on the page.
4. Bingo. However, you cannot count on this being the case forever.
Google already pulls other URLs out of Flash files... it's probably
just a matter of time before it gets better at quickly determining
whether files are subcontent or separate pages. Don't bank on this
staying the case forever.
As for the reasons you should avoid Flash for SEO:
1. 2. 3. 4. and 5. Right on.
6. Google's getting better, and this is the next easiest problem to
solve. I wouldn't count on the relationship between JS and Flash
being confusing to the Googlebot for more than a few internet
generations.
As for your suggestions, you're totally right with the first bit.
Search engines, not just Google, still understand the dynamics of
sites built in good old HTML better than they understand sites built
in Flash. Beussery has pointed out the most obvious issues with the
proposed backup strategy: duplicate content, and URL/linking
consistency.
My advice is the same advice I've given for a good long while: Build
your site first in HTML. Style it using CSS. If you must, do simple
user interaction in Javascript. If you cannot resist, include
multimedia content in Flash. However, remember that each of the
standards evolved into their role for a reason, and while other
technologies have fallen by the wayside, Flash fills the niche for
highly interactive and multi-media experiences on the web. Don't use
it for something when there's already a standard whose output can be
easily parsed, easily processed, and whose openness makes its
processing easier for browsers and searchbots.
Thanks for the great post, abhay.mathur84. This is one of the most
intelligent discussions of the interplay between the new state of
Google's crawl and the commercial use of Flash. This is definitely
worth starring for later review and discussion.
-Bergy
> >What has changed?
> >1. Google can now index the textual content in SWF files of all
> >kinds, including buttons, menus and self-contained Flash websites.
> Not exactly, Google has made some improvements but can't index text
> all content in all SWF files of all kinds and in every case. For
> example, content loaded into SWF files dynamically from another
> source, isn't indexed at all.
> >As mentioned
> >above, Google won’t index content in images and it has problems with
> >JavaScript calls.
> Not exactly, Google supports common JavaScript techniques like those
> used for SWFObject and SWFObject2.
> >Use JavaScript and CSS to find out if the website visitor can
> >parse Flash and then present the CSS DIVs that contain the
> >corresponding content.
> Wait, you just said Google indexes Flash! By adding corresponding
> content to real content in Flash, you've created duplicate content.
> Perhaps why Google doesn't recommend techniques like SWFObject.
> >Use different URLs for different sections of your website. Each
> >set of content should have its own unique URL.
> 1.) Googlebot ignores #anchors in URLs, which you'll need to forward
> the playhead in "the flash file".
> 2.) By creating a different URL for different pages and copying the
> same SWF into each page, you are duplicating content across each page
> as well as running the risk of text contents in the SWF found in each
> "page" not exactly matching content also see by engines in the code of
> "page" where said SWF is housed. Doing this for at all, much less for
> an entire "section" of a site complicates things even more....
> 3.) While duplicate content in Flash may not be penalized, creating
> another version for engines only to have it filtered from results,
> kind of defeats the purpose? In addition to this other "set" of
> content being filtered the technique mentioned also acts to thin
> PageRank as well as keyword relevancy from the anchor text of inbound
> links.
> Either use Flash or don't, either way I'd avoid mixing old and what
> some would call risky techniques for optimizing Flash in Google's new
> Flash environment. Just my two cents, best of luck to you! :)
> On Aug 28, 1:01 am, abhay.mathur84 wrote:
> > A month ago, Google announced that they had improved the way it
> > indexesFlashfiles. Has something changed in Google’s search results
> > in the meantime? Is this change good news for you if you have aFlash
> > site?
> > What has changed?
> > 1. Google can now index the textual content in SWF files of all
> > kinds, including buttons, menus and self-containedFlashwebsites.
> > 2. Google can also discover URLs that appear inFlashfiles and
> > it adds these URLs to the crawling pipeline.
> > What has not changed?
> > 1. Google still doesn’t recognize the text that appears on
> > images. FLV files, such as YouTube videos also won’t be indexed
> > because they don’t contain text.
> > 2. As manyFlashwebsites consist of images and other
> > multimedia elements, the only text that Google finds on these websites
> > might be “Loading”, “Please wait” or “Copyright”.
> > 3. Google also cannot execute some JavaScript types. If your
> > website loads aFlashfile via JavaScript, Google might not be able to
> > find yourFlashfile.
> > 4. In addition, Google cannot attach content from external
> > sources that are loaded byFlashfiles. If yourFlashpage loads an
> > HTML or XML file then these files will be treated as separate
> > documents.
> > Why isFlashstill a problem for search engines?
> > Flashcontent and regular HTML pages are fundamentally different.
> > Just because Google can now index some text fromFlashfiles doesn’t
> > mean thatFlashfiles are now search engine friendly. Here’s why:
> > 1. It’s hard to divide the text into meaningful sections.Flash
> > doesn’t use <h1> or <p> tags to separate different sections of text.
> > It’s hard to tell what’s important and what’s not. Even worse,Flash
> > designers often break down words into their individual letters to
> > create “cool” text effects. That means that search engines cannot
> > index these texts.
> > 2. Usually, the complete content of a website is presented on
> > the same URL. You cannot link to a special part of aFlashwebsite.
> > That means that it is also difficult for search engines to find the
> > relevant section of theFlashsite.
> > 3. In addition, this means thatFlashwebsites don’t get good
> > inbound links to the right pages. MostFlashwebsites only get links
> > to their home page.
> > 4. The structure ofFlashwebsites makes it difficult to get
> > high rankings. ManyFlashfiles are linked from otherFlashfiles and
> > no other websites link to these internalFlashelements. The lack of
> > links from other websites makes it very difficult to get high rankings
> > for these elements.
> > 5.Flashdoesn’t use the basic SEO methods. You won’t find
> > proper link texts, headline tags or even properly optimized title tags
> > in mostFlashsites. That makes it very difficult to get good
> > rankings.
> > 6. MostFlashcontent is still not crawlable. As mentioned
> > above, Google won’t index content in images and it has problems with
> > JavaScript calls.
> > What can you do to improve your rankings if you have aFlashsite?
> > If possible, avoid pureFlashwebsites and useFlashelements only
> > when needed. If you must useFlashon your website, the following tips
> > will help you to get better rankings:
> > Include the text and the links from theFlashfile in an HTML
> > version on the same page.
> > Use JavaScript and CSS to find out if the website visitor can
> > parseFlashand then present the CSS DIVs that contain the
> > corresponding content. Regular website users will see theFlashfile,
> > visitors who cannot parseFlash(for example search engines) will see
> > the HTML version.
> > 1. Use CSS and create a layer with your regular HTML content
> > and then position another layer with theFlashcontent above the HTML
> > layer so that your website visitors only see
Another thing is that it would be great for accessibility
and for mobile phone browsers if in the future
there will be a 'view as HTML' feature in Google search results
for Flash sites as it is now for PDF files.
Hi Beussery,
What I meant with that link to best practices
for accessibility in Flash (anyway I gave it just as an example)
is that Adobe / Macromedia
have many accessibility features embedded in Flash
(probably some plug-ins as well),
that is to extract text, forms, follow pressed buttons, etc.
I was wondering if a good understanding and following of
guidelines for accessibility in Flash might help also with
a site's good visibility for the Google deep crawl of Flash.
> Hi Beussery,
> What I meant with that link to best practices
> for accessibility in Flash (anyway I gave it just as an example)
> is that Adobe / Macromedia
> have many accessibility features embedded in Flash
> (probably some plug-ins as well),
> that is to extract text, forms, follow pressed buttons, etc.
Hey cristina and sorry for not understanding your question.
> I was wondering if a good understanding and following of
> guidelines for accessibility in Flash might help also with
> a site's good visibility for the Google deep crawl of Flash.
Great question!
Since Google's introduction of the new Flash algorithm, Googlebot's
accessibility to text content in Flash is in many ways independent of
traditional browser constraints of the past and as a result, not
impacted to the same degree by published "accessibility guidelines"
for Flash. In many cases Google now "sees" both text content in Flash
(due to the new algorithm) as well as the (X)HTML content employed by
various techniques used to make Flash "accessible".
While not a penalty, non-malicious duplicate content can thin PR and
relevancy from inbound link anchor text making higher rankings more
difficult. JavaScript and (X)HTML don't make Flash more accessible,
they make duplicate content which Google now sees.
To satisfy both search engines and accessibility requirements, I'd
suggest not including text content in Flash unless it's dependent and
originates from the same URL (sIFR) or creating an (X)HTML version of
your site disallowing Flash.
Thank you very much for your great reply!
As Bergy recommended, I already bookmarked this thread.
Sorry, I try again to clarify, I was not referring to
if Google index is 'impacted by accessibility guidelines'
(to quote your learned posting),
but
I was wondering if when extracting content from Flash
Googlebot might not be using features similar to
those used by software of accessibility plug-ins for Flash.
> > Hi Beussery,
> > What I meant with that link to best practices
> > for accessibility in Flash (anyway I gave it just as an example)
> > is that Adobe / Macromedia
> > have many accessibility features embedded in Flash
> > (probably some plug-ins as well),
> > that is to extract text, forms, follow pressed buttons, etc.
> Heycristinaand sorry for not understanding your question.
> > I was wondering if a good understanding and following of
> > guidelines for accessibility in Flash might help also with
> > a site's good visibility for the Google deep crawl of Flash.
> Great question!
> Since Google's introduction of the new Flash algorithm, Googlebot's
> accessibility to text content in Flash is in many ways independent of
> traditional browser constraints of the past and as a result, not
> impacted to the same degree by published "accessibility guidelines"
> for Flash. In many cases Google now "sees" both text content in Flash
> (due to the new algorithm) as well as the (X)HTML content employed by
> various techniques used to make Flash "accessible".
> "Serving the same content in Flash and an alternate HTML version could
> cause us to find duplicate content. This won't cause a penalty -- we
> don’t lower a site in ranking because of duplicate content."http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-ind...
> While not a penalty, non-malicious duplicate content can thin PR and
> relevancy from inbound link anchor text making higher rankings more
> difficult. JavaScript and (X)HTML don't make Flash more accessible,
> they make duplicate content which Google now sees.
> To satisfy both search engines and accessibility requirements, I'd
> suggest not including text content in Flash unless it's dependent and
> originates from the same URL (sIFR) or creating an (X)HTML version of
> your site disallowing Flash.
> I was wondering if when extracting content from Flash
> Googlebot might not be using features similar to
> those used by software of accessibility plug-ins for Flash.
Yes, they might be but to what extent I'm not sure anyone but Google
knows.
> > I was wondering if when extracting content from Flash
> > Googlebot might not be using features similar to
> > those used by software of accessibility plug-ins for Flash.
> Yes, they might be but to what extent I'm not sure anyone but Google
> knows.
If you are offering an html equivalent of a Flash page/site. Where do
you put it? Is it on a different page? Or is it behind the Flash? It
seems like either way would be suboptimal, especially if you want your
Flash page indexed, not your html equivalent.
What are best practices for offering dual Flash/html versions?
The best practice is still to keep your text content and navigation in
HTML, to use CSS for presentation, and use Flash only for the parts
that need to be in Flash, like videos, games, and animations.
All other options may cause unsatisfactory duplicate content
concerns. Figure out how you want your user to interact with the page
and then design around that. Personally I would suggest attempting to
keep your Flash and HTML content at the same URL using Javascript or
stylish prompts to determine whether the user would prefer to see
Flash. Hoewever, you need to make EXTRA sure that the content
presented in the Flash and HTML are the same, otherwise, you may run
afoul of the webmaster guideline against cloaking or sneaky
Javascript.
> If you are offering an html equivalent of a Flash page/site. Where do
> you put it? Is it on a different page? Or is it behind the Flash? It
> seems like either way would be suboptimal, especially if you want your
> Flash page indexed, not your html equivalent.
> What are best practices for offering dual Flash/html versions?
That's how I currently do it. I don't see a reason to have a full
Flash site, and only use Flash for pieces that need to be Flash. But
in hypothetical pondering I was banging my head against duplicate
content issues.
> The best practice is still to keep your text content and navigation in
> HTML, to use CSS for presentation, and use Flash only for the parts
> that need to be in Flash, like videos, games, and animations.
> All other options may cause unsatisfactory duplicate content
> concerns. Figure out how you want your user to interact with the page
> and then design around that. Personally I would suggest attempting to
> keep your Flash and HTML content at the same URL using Javascript or
> stylish prompts to determine whether the user would prefer to see
> Flash. Hoewever, you need to make EXTRA sure that the content
> presented in the Flash and HTML are the same, otherwise, you may run
> afoul of the webmaster guideline against cloaking or sneaky
> Javascript.
I'd be lying if I said I hadn't also banged my head against the same
thing in my little Gedanken about this. The only answer I came up
with for how to have an HMTL page with the same text content in Flash
without duplicate content arising was to use a Flash as what would
essentially be an additional rendering engine... to write a textless
Flash file to load via Javascript to pull the content from the HTML
DOM and then display it. On a small scale, this is what sIFR does,
and we all love sIFR.
The problem is that no one in their right mind would want to write a
whole rendering engine in Flash, because the engine itself would be
slow, the download time would be long, the renderer likely wouldn't
conform to standards, and the work would be tedious and not at all
pleasant.
However, at risk of setting the internet on fire, I've long wondered
WHY anyone feels like their static text content needs to be in Flash.
It's text! CSS has such a powerful ability to style and present
static text content that Flash seems like overkill to me. If you want
fancy Flash scrollbars or something, you can build them and use them
to play with the DOM and scroll things with the text in HTML.
However, as I have been divorced from the production side of things
for a while, I know other people have valuable experience to share--
any good answers, special cases, or counterexamples floating out
there?
> That's how I currently do it. I don't see a reason to have a full
> Flash site, and only use Flash for pieces that need to be Flash. But
> in hypothetical pondering I was banging my head against duplicate
> content issues.
> On Sep 2, 11:41 am, Bergy wrote:
> > The best practice is still to keep your text content and navigation in
> > HTML, to use CSS for presentation, and use Flash only for the parts
> > that need to be in Flash, like videos, games, and animations.
> > All other options may cause unsatisfactory duplicate content
> > concerns. Figure out how you want your user to interact with the page
> > and then design around that. Personally I would suggest attempting to
> > keep your Flash and HTML content at the same URL using Javascript or
> > stylish prompts to determine whether the user would prefer to see
> > Flash. Hoewever, you need to make EXTRA sure that the content
> > presented in the Flash and HTML are the same, otherwise, you may run
> > afoul of the webmaster guideline against cloaking or sneaky
> > Javascript.
It seems to me that Googlebot finding URLs embedded in Flash may be of
little value when those URLs contain #anchors. Is that correct, does
Googlebot treat #anchors in URLs which are embedded Flash the same as
#anchors in URLs in (X)HTML?
> I'd be lying if I said I hadn't also banged my head against the same
> thing in my little Gedanken about this. The only answer I came up
> with for how to have an HMTL page with the same text content in Flash
> without duplicate content arising was to use a Flash as what would
> essentially be an additional rendering engine... to write a textless
> Flash file to load via Javascript to pull the content from the HTML
> DOM and then display it. On a small scale, this is what sIFR does,
> and we all love sIFR.
> The problem is that no one in their right mind would want to write a
> whole rendering engine in Flash, because the engine itself would be
> slow, the download time would be long, the renderer likely wouldn't
> conform to standards, and the work would be tedious and not at all
> pleasant.
> However, at risk of setting the internet on fire, I've long wondered
> WHY anyone feels like their static text content needs to be in Flash.
> It's text! CSS has such a powerful ability to style and present
> static text content that Flash seems like overkill to me. If you want
> fancy Flash scrollbars or something, you can build them and use them
> to play with the DOM and scroll things with the text in HTML.
> However, as I have been divorced from the production side of things
> for a while, I know other people have valuable experience to share--
> any good answers, special cases, or counterexamples floating out
> there?
> -Bergy
> On Sep 3, 10:23 am, metronome wrote:
> > Thanks Bergy,
> > That's how I currently do it. I don't see a reason to have a full
> > Flash site, and only use Flash for pieces that need to be Flash. But
> > in hypothetical pondering I was banging my head against duplicate
> > content issues.
> > On Sep 2, 11:41 am, Bergy wrote:
> > > The best practice is still to keep your text content and navigation in
> > > HTML, to use CSS for presentation, and use Flash only for the parts
> > > that need to be in Flash, like videos, games, and animations.
> > > All other options may cause unsatisfactory duplicate content
> > > concerns. Figure out how you want your user to interact with the page
> > > and then design around that. Personally I would suggest attempting to
> > > keep your Flash and HTML content at the same URL using Javascript or
> > > stylish prompts to determine whether the user would prefer to see
> > > Flash. Hoewever, you need to make EXTRA sure that the content
> > > presented in the Flash and HTML are the same, otherwise, you may run
> > > afoul of the webmaster guideline against cloaking or sneaky
> > > Javascript.
Hi beussery
When we find URLs with an anchor attached like that (http://domain.com/ page#anchor) we generally ignore the anchor part, since it is not
relevant when fetching the contents of a URL. In other words, if you
use these anchors for navigation within a Flash file, I would
recommend also providing alternate forms of navigation through the
rest of the URL.
Hope it helps, and thanks, Bergy, for giving us your insights!
John
Even static text may need to be Flash-ized if you have particular font
in mind or something. CSS only has the ability to use system fonts. If
you come from a print background this can be very frustrating. Never
really bothered me yet, but, I can see how in some particular designs
it would. I guess that's what Sifr is for.
> I'd be lying if I said I hadn't also banged my head against the same
> thing in my little Gedanken about this. The only answer I came up
> with for how to have an HMTL page with the same text content in Flash
> without duplicate content arising was to use a Flash as what would
> essentially be an additional rendering engine... to write a textless
> Flash file to load via Javascript to pull the content from the HTML
> DOM and then display it. On a small scale, this is what sIFR does,
> and we all love sIFR.
> The problem is that no one in their right mind would want to write a
> whole rendering engine in Flash, because the engine itself would be
> slow, the download time would be long, the renderer likely wouldn't
> conform to standards, and the work would be tedious and not at all
> pleasant.
> However, at risk of setting the internet on fire, I've long wondered
> WHY anyone feels like their static text content needs to be in Flash.
> It's text! CSS has such a powerful ability to style and present
> static text content that Flash seems like overkill to me. If you want
> fancy Flash scrollbars or something, you can build them and use them
> to play with the DOM and scroll things with the text in HTML.
> However, as I have been divorced from the production side of things
> for a while, I know other people have valuable experience to share--
> any good answers, special cases, or counterexamples floating out
> there?
> Hi beussery
> When we find URLs with an anchor attached like that (http://domain.com/ > page#anchor) we generally ignore the anchor part, since it is not
> relevant when fetching the contents of a URL. In other words, if you
> use these anchors for navigation within a Flash file, I would
> recommend also providing alternate forms of navigation through the
> rest of the URL.
> Hope it helps, and thanks, Bergy, for giving us your insights!
> John
|
