On Sat, 30 Apr 2005, Mike Lesser wrote:
> > Current versions of CGI.pm should generate XHTML by default, iirc.
>
> Hmm. Does it include the doctype stuff and so forth?
Test it and find out.
$ cat ~/Sites/test.cgi
#!/usr/bin/perl -T
use strict;
use warnings;
use CGI;
use CGI::Carp qw( fatalsToBrowser );
my $q = new CGI;
print $q->header();
$ lynx -dump -head http://localhost/~mlesser/test.cgi
... what happens? Try it and see.
> I guess there's no need to settle on using just CGI.pm, right? Using
> both CGI.pm and print qq isn't considered gross?
It doesn't bother me, but others might complain about it.
My point of view is that a mix of print statements and CGI.pm methods is
fine for basic CGI scripts, but a proper template engine -- Template
Toolkit, HTML::Template, or Mason -- should be used for anything that is
getting at all complex.
> > > (2) My stylesheets don't work with @import - Apache claims that it
> > > can't find the file. They _do_ work with a hard reference like
> > > <link rel="stylesheet" type="text/css"
> > > href="http://localhost/the_stylesheet.css"; />
> >
> > If you really really want to have them in an @import call in the HTML,
> > reconsider. The <link ...> approach should be fine. If you still want
> > to do it this way, please clarify how you're trying to implement it.
>
> [The only reason I'm trying it is because the book (my first CSS book)
> uses it in the examples; it says that older browsers won't choke on
> the stylesheets. Frankly, I don't care about any older browsers at the
> moment! Also I don't even know where this @import symbol comes from!
> If the link tag method is considered to be sufficient, then hey, I'm
> fine with that for now.]
Okay then, back up for a minute. I'm aware of three ways to import CSS
style information into HTML text:
* directly in place, within a <style> block:
<style>
blink { text-decoration: none ! important; }
</style>
* by @import'ing a separate URL from within a <style> block:
<style>
@import "/css/my_global_styles.css"
@import "my_local_styles.css"
</style>
* by using <link> tags in the <head> section of the HTML source:
<link rel="stylesheet" type="text/css" href="/css/my_global_styles.css" />
<link rel="stylesheet" type="text/css" href="my_local_styles.css" />
Most pages I've looked at seem to use the <link> approach, unless the
style code is being placed inline, but that seems much less common.
While any of the three should work equally well in practice, if you're
hitting a wall on one of these then why bother using it if the others
don't have the problem?
> I _definitely_ can take the CGI-created source and make it a static
> web page, and it will find the stylesheet (by just its name) just fine
> - no problems at all. This is true for both the global web folder and
> my personal one. (Naturally the stylesheets and js files are in both
> places). This makes me think it's Apache.
Maybe, but I can't think of how that would be.
Every CSS reference should map to a URL. If it's a relative url -- like
"style.css" -- then you can access it by going to the same URL as your
CGI script and replacing "foo.cgi" with "style.css"; if this works, then
Apache is fine; if it doesn't, then your Apache is configured in a way
that doesn't agree with what you're doing.
(If you're serving your CGI scripts out of a ScriptAlias'ed directory
rather than by file extension, then Apache will attempt to *execute*
your CSS file rather than just return its contents -- this will
*definitely* break on most platforms, including your Mac; this will be
obvious if you request the URL directly because you'll get a 500 Server
Error response from Apache.)
The fix may be to make CSS references absolute -- "/css/style.css" or
"http://mysite.com/css/style.css";. This should if nothing else make the
class of errors in the last paragraph much less likely. It would also
mean that you can move the CGI file around without breaking links, which
could be useful over the life of this script.
> Inside my head tag I have this.
> <link rel="stylesheet" type="text/css"
> href="http://localhost/~mike/07_p188_adding_separator_stripes.css";
> /></link>
That's not valid XHTML.
The "<foo/>" idiom is shorthand for "<foo></foo>".
Therefore, "<foo/></foo>" is equivalent to "<foo></foo></foo>".
Don't do that :-)
> <script src="http://localhost/07_p188_adding_separator_stripes.js";
> type="text/javascript"></script>
>
> (and yeah, the goofy file names are from the book examples' site)
>
> Now if I have a full href to the stylesheet - http://localhost/<that
> giant name> - it won't be used and the Apache log will reflect this.
> Likewise with a partial href to the file. But the javascript src tag
> seems to be a lot smarter!
...that and the Javascript isn't broken. Fix your HTML and try again;
the results may get more predictable once you do so :-)
> ------------------------------------------------------------------------
> ------------
> Just for kicks;
>
> The original version using the import, btw, looks like this inside the head
> tag:
> <style type="text/css" title="text/css">
> /* <![CDATA[ */
> @import url(07_p188_adding_separator_stripes.css);
> /* ]]> */
> </style>
> <script src="07_p188_adding_separator_stripes.js"
> type="text/javascript"></script>
What ???
Delete that /* ... */ crap. Is it supposed to serve some purpose? You
can very safely do without it, and things will get much more readable.
--
Chris Devers
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
