PDA

View Full Version : Validate Fade-In Slideshow? & Opera Question, too



sel_nyc
02-16-2005, 06:40 PM
Fade-In Slideshow

http://www.dynamicdrive.com/dynamicindex14/fadeinslideshow.htm

Love this script, but I have two questions:

1.) As someone who sells web development services to small businesses, I feel that W3C validation is just one of those things you do for your client's websites as a mark of your professionalism. It's independent verification that you, at the very least, know what you're doing.

Having said that, I've tried to get the above script to validate as XHTML 1.0 Transitional, and was able to resolve the easy issues like the lack of alt tags, but cannot figure out how to resolve the remaining issues, which may be seen here at the W3C site validator:

http://validator.w3.org/check?verbose=1&uri=http%3A//tesla-pc.com/services/develop/

Original page may be seen here:

http://tesla-pc.com/services/develop/

Any help would be greatly appreciated.

2.) The script works terrifically in IE, Firefox and NS; in Opera it degrades to a regular slide show. It's not a big deal--as degradations go, this is a very acceptable one--but I'm cur
ious to know if anyone's found a workaround.

ddadmin
02-17-2005, 02:02 AM
Ok, try this instead:

<script>
// <[CDATA[
"
"
// ]]>
</SCRIPT>

I tested it, and the slideshow still works on your page. The script should validate as a result still. Make sure you add the part in bold to both scripts on your page.

sel_nyc
02-17-2005, 02:19 AM
Yeah, now it's trying to parse the first bracket of the CDATA declaration as data instead of a character.

But the slideshow works.

How important is it that I place this tag around all of the js on my page?

For example, this page:

http://tesla-pc.com/resources/wallpapers/index.htm

Also contains that little time/date thing on the bottom, plus a little js sniffer for the UA's screen resolution and it validates as XHTML 1.0 Transitional, as do all my other pages. I'm kind using this as, not really a selling point, 'cause --nothing against them--but my clients wouldn't know the difference, but as a way of demonstrating a level of proficiency in web design.

Yeah, big frickin' deal.

At any rate, the material I've read seems to indicate you'd use the CDATA tag just anywhere there was character data (cleverly named, ain't it) that you didn't want parse as anything but characters...or something.

Those other scripts (I think one of them is yours) validate; I think I had to fiddle with 'em a bit, but they've offered no problem since.

OK, getting hungry and confused now. Must eat.

ddadmin
02-17-2005, 02:29 AM
No problem. BTW I've deleted the previous two posts just to avoid confusion by other people who may view this thread.

sel_nyc
02-17-2005, 02:46 AM
OK, so we were, like, typing this at the same time, huh?

Well, you were typing, I was editing. I just hadn't tersted the validation part before i spoke. Sorry about that.

ddadmin
02-17-2005, 03:46 AM
Hmmm so just to clarify, bottom line, does the page with the Fade In slideshow now validate?



How important is it that I place this tag around all of the js on my page?


I'm probably not the best person to ask this, since I'm not fully immersed in xhtml/ xml coding yet. If a script validates even without <[CDATA[, then most likely it happens to not contain any special characters of xhtml/ xml. In that case, is it necessary to still have <[CDATA[? Maybe in XML, not sure about xhtml, but if it validates, ultimately that should be your sign of approval.

sel_nyc
02-17-2005, 04:36 AM
I'm sorry I didn't make that clearer in my previous post.

No, it doesn't validate.

As I just validated all my sites last month--sort of on a whim and because the things that kept them from validating were so relatively easy to fix--I am by no means an expert on XML myself.

So, to recap, with the original <[CDATA[ & ]]> tags, the page will validate but the slideshow doesn't work--degrades to, well, nothing.

With the addition of the slashes, the slideshow works, but the page won't validate as XHTML 1.0 Transitional.

After looking at the notations at the W3C site and elsewhere, I agree with you--this looks like it should work, though they don't specifically call for its use in a js scenario.

My sense is that because the CDATA looks at the js as characters it disables it's very essence as dynamic code.

There are other tags, <IGNORE> for example (which won't work, just an example), that I came across that I'll play with. We certainly can't be the first people to try to validate 100 lines of js.

Of course, I'll post back here with whatever results I find.

I think as newer browsers are released (IE 7 this summer, for example, according to Bill Gates yesterday), the trend is for them to be more standards-based and use less proprietary-based code as in years past--during the browser wars of the mid-90's, for example.

So I think validation is going to become, pardon me for the bad pun, a more valid way of making web pages, which impacts on every piece of code on your site, as well.

I'll let you know what I find out.

sel_nyc

ddadmin
02-17-2005, 06:04 AM
Ok, lets try this again:

<script type="text/javascript">
<!-- <![CDATA[

rest of script

// ]]> -->
</script>

I tried the above on a valid blank page with just a DHTML script, and it validates.

sel_nyc
02-17-2005, 03:07 PM
Awwwl-riiiight!

Yes, the script works and the page validates as XHTML 1.0 Transitional.

Here's the page:

http://tesla-pc.com/services/develop/

And here are the validation results:

http://validator.w3.org/check?verbose=1&uri=http%3A//tesla-pc.com/services/develop/

Well done!

mwinter
02-17-2005, 05:37 PM
<script type="text/javascript">
<!-- <![CDATA[

rest of script

// ]]> -->
</script>The SGML comment delimiters are unnecessary. This has been true - for both script and style data - since third generation browsers dropped out of wide-spread use (which was several years ago). More to the point, with XHTML documents they are harmful: a conforming user agent will completely ignore any content within the delimiters.

As far as the CDATA processing instructions are concerned, they are only useful for XHTML document served as XHTML. The site in question serves HTML[1].

The only correct way to serve non-trivial script or style data is via an external file. This is especially important if that data is used in more than one document (which is the case here).

Mike


[1] To be frank, if you aren't serving XHTML as XHTML, you may as well be using plain HTML. If not, all you are doing is forcing the user agent to error-correct the entire document into HTML which does nothing more than waste processor cycles.

In addition, if you're going to take the time to use a more "modern" mark-up language, you could at least use more modern mark-up: the Transitional DTD in both XHTML and HTML is simply a stop-gap measure for legacy documents that use deprecated features. Any document authored in the last couple of years should be using a Strict DTD and not HTML 3.2 techniques like layout-tables.

sel_nyc
02-17-2005, 09:06 PM
The SGML comment delimiters are unnecessary. This has been true - for both script and style data - since third generation browsers dropped out of wide-spread use (which was several years ago). More to the point, with XHTML documents they are harmful: a conforming user agent will completely ignore any content within the delimiters.

It's funny, Mike, but I was just talking to one of my client's on the street in front of my apartment a few minutes ago, kinda marvelling that two years ago today I'd never even created a single web page and now I've designed and continue to maintain six of them, including my own. They can all be seen from here:

http://tesla-pc.com/services/develop/clients.htm

I started out by just trying to get the pages to work in IE, NS and Opera, later adding FF; I have a friend who uses Apple's Safari & IE for Mac, so I chek 'em there, too. My attempts at validation, as stated above, only started when I found myself with time on my hands after the New Year. For me, it was a bit of a lark.

As I have no degrees or academic credits in web design (we didn't have web pages when I went to school many, many years ago), I am by no means positioning myself as an expert here, but I am learning something new everytime I create a new site or validate a bunch of older ones. And I learn quite a lot by visiting forums just like this one and talking to guys like you.


As far as the CDATA processing instructions are concerned, they are only useful for XHTML document served as XHTML. The site in question serves HTML[1].

Any XHTML 1.0 document, strict or otherwise, is derived from the three previous HTML 4.0 specs, as illustrated by this quote from the W3C:


XHTML 1.0 (this specification) is the first document type in the XHTML family. It is a reformulation of the three HTML 4 document types as applications of XML 1.0 [XML]. It is intended to be used as a language for content that is both XML-conforming and, if some simple guidelines are followed, operates in HTML 4 conforming user agents.

I know my XHTML 1.0 Transitional documents aren't the end-all and be-all of web creation, but they do what I want them to do and they render correctly both cross-browser and cross-platform.

What else does a web site need?

As most past browsers and many current ones aren't ready for pure XHTML, much less pure XML, they can still render these pages correctly, though it roasts my chestnuts that they all look better on the Macs.



The only correct way to serve non-trivial script or style data is via an external file. This is especially important if that data is used in more than one document (which is the case here).

And I would love to learn how to use this stuff externally and one day I will. Any help you wanna give me in this endeavor, any documents I could read that would help me along with it, would be gratefully appreciated. Also, it sounds way cool.

But the only script that's being served to multiple pages is not the fade-in slideshow script, but the little day and date stamp at the bottom--my first attempt at using js, which has validated very nicely all along since, well, not Day One, but Day Two.


[1] To be frank, if you aren't serving XHTML as XHTML, you may as well be using plain HTML. If not, all you are doing is forcing the user agent to error-correct the entire document into HTML which does nothing more than waste processor cycles.

In addition, if you're going to take the time to use a more "modern" mark-up language, you could at least use more modern mark-up: the Transitional DTD in both XHTML and HTML is simply a stop-gap measure for legacy documents that use deprecated features. Any document authored in the last couple of years should be using a Strict DTD and not HTML 3.2 techniques like layout-tables.

Yeah, and I'd like to be able to create pages without having to check them in a whole bunch of different user agents, but I can't.

XHTML 1.0, strict or otherwise, is not ready for prime time just yet; it's clearly a stopgap measure until there are more UA's that can handle their output. That's the point of the W3C documentation as quoted above and that's the world I live in, where I have to sell my web services to paying clients.

They don't care a whit whether or not their sites validate--they just wanna know how this site is gonna make and save money for them--and they're exactly right. I validate them as a point of pride. The next time I go through the process, I will attempt to the strict validation, but that's gonna be a ways off.

Anyway, thanks for your input, Mike--you've certainly whetted my curiosity and I see more research for me on this topic in the weeks and months ahead.

Steve

mwinter
02-17-2005, 11:28 PM
My attempts at validation, as stated above, only started when I found myself with time on my hands after the New Year. For me, it was a bit of a lark.If you do continue to author XHTML, you have little choice but to validate your mark-up. Do not forget that a conforming user agent is supposed to stop processing your document if it encounters an error. This is why XHTML is good for mobile devices: they don't have to worry about error correction, they can just quit and say the author didn't do his or her job right. If only that could happen with HTML...



The site in question serves HTML.Any XHTML 1.0 document, strict or otherwise, is derived from the three previous HTML 4.0 specs, as illustrated by this quote from the W3C:What I was referring to is the content-type HTTP response header sent by your server. It is this, and only this, that a user agent should use to determine what the server is sending.

HTML is always served as text/html, but there are a few ways to send XHTML. The correct way is using application/xhtml+xml. However, this will cause user agents which do not recognise XHTML to fail to render the document properly. This was why XHTML 1.0 (but not later versions, if I recall) allowed a special form of XHTML to be served as text/html.

The argument here is that if you need to do this, you shouldn't be serving XHTML in the first place. There is no advantage in doing so. As I stated previously, every user agent - even those that could handle XHTML properly - will take your nice, neat validated document and slurp it up as tag soup. Even if you're writing XHTML because you're using XML tools, you can still have such tools transform the output into HTML.

XHTML might be beneficial to mobile devices as an XML parser is leaner than a tag soup (that is, HTML) parser, but you're obviously not writing for that audience (nested tables probably aren't a good idea for portable devices).


As most past browsers and many current ones aren't ready for pure XHTMLThat's my point. So why are you using XHTML? Sorry if I seem to be badgering you, but I'm interested to know why you aren't content with HTML. It won't be going away for a very long time, and valid HTML is just as good as valid XHTML.


And I would love to learn how to use this stuff externallyAs far as inclusion is concerned, it's very simple. Take the script (none of the processing instructions, just the code), place it in a file with a .js extension, then add an src attribute to the opening tag of your script elements.

With regards to writing, there's no change. However, there are certainly differences between authoring for an XHTML document and an HTML document. For instance, there is no document.write method. If you served your pages properly, none of the scripts would work.


Yeah, and I'd like to be able to create pages without having to check them in a whole bunch of different user agents, but I can't.Unless you manage to find and remember all the various rendering bugs present in every user agent (especially IE), you'll always be checking your work in as many UAs you can get your hands on. However, writing standard's-compliant, semantic mark-up usually makes things easier.

Mike

sel_nyc
02-18-2005, 06:00 AM
Mike, you and I are in substantial agreement.

Except for the parts where we're not.

But those parts aren't all that important.

Yes, I want to know more, I want to do better, I want to be able to prepare all my sites for whatever future UAs come down the pike.

I am working toward that end, perhaps not as quickly as you might like, but there are other responsibilities--not to mention other distractions--that must be dealt with, as well.

I wish I could devote all my time to my work on web sites, but I occasionally have to leave my computer to repair someone else's or remove KaZaa from the machine of some other user who couldn't be bothered to read just what they were gonna have to give up in clock cycles in order to run that "free" program or just to get some fresh air.

I promise I will try to do better, but you gotta cut me some slack, guy. I'm running as fast as I can...

Best regards,

Steve

mwinter
02-18-2005, 12:41 PM
If you do continue to author XHTML, you have little choice but to validate your mark-up. Do not forget that a conforming user agent is supposed to stop processing your document if it encounters an error.I should probably qualify that a little better. XHTML documents must be well-formed. If not, it is a requirement that a user agent stops processing the document (except to find more errors, if it wants). For this reason, it is a good idea to validate documents.


Mike, you and I are in substantial agreement.That's good to know. :D


Except for the parts where we're not.Well, everyone's entitled to their opinions. I only offer mine - you don't have to take it.


I promise I will try to do better, but you gotta cut me some slack, guy.I'm pretty sure I wrote that I'm not trying to harrass you. I offer a sincere apology if you felt differently.

Lots of people do things because it's perceived as the best approach without understanding why. There have been two examples in this thread: using SGML comment delimiters in script/style elements, and adopting XHTML. Both are fine for the right reasons[1], but there's nothing to gain by just jumping on the band wagon.

Mike


[1] Though the right reasons for the former ended several years ago.