Newbie's CSS not having an effect.

[Jonathan N. Little]

I didn't claim that it offered any advantages. I merely pointed out that your
claim of the supposed "complications" doesn't hold any water.

Ian quite effectively lays out the "complications" and pitfalls, (and
the numerous cries for help in the very NG novices get bit by xhtml)

http://hixie.ch/advocacy/xhtml

Also if you claim "no advantages" what is the point?

<obscure_cartoon_ref>
Said the Tallest, "Because it is aaaaaadvanced!"
</obscure_cartoon_ref>

 

[Larry Lindstrom]

Thanks Again C A and Jonathan:

I guess that means the W3C validation suites aren't sufficient to
ferret out this problem. Now I know where Firefox's error counsel is,
thanks.

That was my guess. I believe that the OP does not have a complete
"default" http.conf but is missing most of it's configuration

There should be LoadModule directives in the global part of the
httpd.conf The one missing I think is

LoadModule mime_module modules/mod_mime.so

That loads the standard mime types. You could just add

AddType test/css .css

as a hack in the httpd.conf or .htaccess file, but he should really just
add the standard modules in httpd.conf. May Ubuntu/Debian servers add
the modules by having a mods-enabled folder, but old RH and Mandrake
included them in the httpd.conf

A little OT here, the OP should get himself the O'Reilly "pony" boot,
but some typical modules to install are:

LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so

LoadModule auth_basic_module /usr/lib/apache2/modules/mod_auth_basic.so

LoadModule authn_file_module /usr/lib/apache2/modules/mod_authn_file.so

LoadModule authz_default_module
/usr/lib/apache2/modules/mod_authz_default.so

LoadModule authz_groupfile_module
/usr/lib/apache2/modules/mod_authz_groupfile.so

LoadModule authz_host_module /usr/lib/apache2/modules/mod_authz_host.so

LoadModule authz_user_module /usr/lib/apache2/modules/mod_authz_user.so

LoadModule autoindex_module /usr/lib/apache2/modules/mod_autoindex.so

LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so

LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so

LoadModule env_module /usr/lib/apache2/modules/mod_env.so

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so

LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so

LoadModule php5_module /usr/lib/apache2/modules/libphp5.so

LoadModule setenvif_module /usr/lib/apache2/modules/mod_setenvif.so

LoadModule status_module /usr/lib/apache2/modules/mod_status.so

I'm so confused right now I don't know what to do.

In August I downloaded Apache 2.2.13.

I built it from source using Sun's compiler:

$ ./configure --prefix=<Install directory name>
$ make
$ make install

This went without a hitch.

Something I do periodically, for instance today, as root, is run:

find / -depth -print > /opt/local/find_all.

This gives me a list of every file on my system.

I've searched find_all for a file called "mod_mime.so" and found
that no such file exists on my system.

I've searched for "mod_alias.so", "mod_auth_basic.so",
"mod_authn_file.so" and "mod_cgi.so".

Nothing.

A search of the Apache site for "mod_mime.so" turns up a section
titled "Apache Module mod_mime", but a search of that page for
"mod_mime.so" comes up empty.

The module identifier is "mime_module".

The source file is "mod_mime.c". Is there a C file by that name on
my system? Yes there is!

But has it been built? Is it in a library somewhere? I went to
the install directory's lib directory and ran "nm" against the
libraries there. I found nothing.

Where can I find this default httpd.conf file?

I have downloaded the sample files for O'Reilly's Apache book, ran
find and grep only to find the term "mime" is used by one httpd.conf
file. The httpd.conf file for the "site.simple" example. And that
reference is "TypesConfig conf/mime.types".

Speaking of the O'Reilly's Apache book, third edition, on page 40
they recommend against starting with a massive httpd.conf file and
modifying it to fit. They say "It is much better to start with a
completely minimal file and add to it what is absolutely necessary."
Which explains the current state of my httpd.conf files.

I don't know what to do now.

It's into the wee hours here on the US West coast, time for bed.

As I've said so many times in this thread. I appreciate the effort
you two have made to help me.

Thanks
Larry

 

[Jonathan N. Little]

I'm so confused right now I don't know what to do.

In August I downloaded Apache 2.2.13.

I built it from source using Sun's compiler:

$ ./configure --prefix=<Install directory name>
$ make
$ make install

This went without a hitch.

I've always installed the package for my distro so it always
preconfigures with working base install.

Something I do periodically, for instance today, as root, is run:

find / -depth -print> /opt/local/find_all.

This gives me a list of every file on my system.

I've searched find_all for a file called "mod_mime.so" and found
that no such file exists on my system.

I've searched for "mod_alias.so", "mod_auth_basic.so",
"mod_authn_file.so" and "mod_cgi.so".

The modules on my Ubuntu servers is /usr/lib/apache2/modules, for my
website which is Redhat they are /usr/lib/httpd/modules I have no idea
for Solaris but I would assume something similar. I have these modules
available by default:

libphp5.so
mod_actions.so
mod_alias.so
mod_asis.so
mod_auth_basic.so
mod_auth_digest.so
mod_authn_alias.so
mod_authn_anon.so
mod_authn_dbd.so
mod_authn_dbm.so
mod_authn_default.so
mod_authn_file.so
mod_authnz_ldap.so
mod_authz_dbm.so
mod_authz_default.so
mod_authz_groupfile.so
mod_authz_host.so
mod_authz_owner.so
mod_authz_user.so
mod_autoindex.so
mod_cache.so
mod_cern_meta.so
mod_cgid.so
mod_cgi.so
mod_charset_lite.so
mod_dav_fs.so
mod_dav_lock.so
mod_dav.so
mod_dbd.so
mod_deflate.so
mod_dir.so
mod_disk_cache.so
mod_dumpio.so
mod_env.so
mod_expires.so
mod_ext_filter.so
mod_file_cache.so
mod_filter.so
mod_headers.so
mod_ident.so
mod_imagemap.so
mod_include.so
mod_info.so
mod_ldap.so
mod_log_forensic.so
mod_mem_cache.so
mod_mime_magic.so
mod_mime.so
mod_negotiation.so
mod_proxy_ajp.so
mod_proxy_balancer.so
mod_proxy_connect.so
mod_proxy_ftp.so
mod_proxy_http.so
mod_proxy.so
mod_rewrite.so
mod_setenvif.so
mod_speling.so
mod_ssl.so
mod_status.so
mod_substitute.so
mod_suexec.so
mod_unique_id.so
mod_userdir.so
mod_usertrack.so
mod_version.so
mod_vhost_alias.so

A search of the Apache site for "mod_mime.so" turns up a section
titled "Apache Module mod_mime", but a search of that page for
"mod_mime.so" comes up empty.

The module identifier is "mime_module".

The source file is "mod_mime.c". Is there a C file by that name on
my system? Yes there is!

Those would be the recompiled versions. Maybe you did not include them
during your build.

But has it been built? Is it in a library somewhere? I went to
the install directory's lib directory and ran "nm" against the
libraries there. I found nothing.

Where can I find this default httpd.conf file?

Typically it is in:

/etc/apache2/
/etc/httpd

For Apache2 most times httpd.conf is an empty file for legacy and the
actual config is in apache2.conf. Debian breaks up the configuration
into modular configs which I have found very useful, Redhat still puts
everything in one httpd.conf. The source package has template that
should have created the config for your system. The template
httpd.conf.in is in the the tar.gz at httpd-2.2.13/docs/conf I noticed a
mime.types file there that does have text/css defined.

Maybe you should just install the binary package for Solaris

http://archive.apache.org/dist/httpd/binaries/solaris/

It should be already preconfigured with a working default server instead
of rolling your own from the start.

Also the NG more on topic might be alt.apache.configuration...

 

[Doug Miller]

I didn't claim that it offered any advantages. I merely pointed out that your
claim of the supposed "complications" doesn't hold any water.

Ian quite effectively lays out the "complications" and pitfalls, (and
the numerous cries for help in the very NG novices get bit by xhtml)[/QUOTE]

I was addressing specifically the claim that *you* made, not those made by
anyone else.

http://hixie.ch/advocacy/xhtml

Also if you claim "no advantages" what is the point?

I also didn't claim that it offered "no advantages". I made no claims one way
or the other about advantages or lack thereof -- I only pointed out that the
disadvantage *you* claimed exists in fact does not.

 

[Larry Lindstrom]

I've always installed the package for my distro so it always
preconfigures with working base install.








The modules on my Ubuntu servers is /usr/lib/apache2/modules, for my
website which is Redhat they are /usr/lib/httpd/modules I have no idea
for Solaris but I would assume something similar. I have these modules
available by default:

libphp5.so              
mod_actions.so
mod_alias.so
mod_asis.so
mod_auth_basic.so
mod_auth_digest.so
mod_authn_alias.so
mod_authn_anon.so
mod_authn_dbd.so
mod_authn_dbm.so
mod_authn_default.so
mod_authn_file.so
mod_authnz_ldap.so
mod_authz_dbm.so
mod_authz_default.so
mod_authz_groupfile.so
mod_authz_host.so
mod_authz_owner.so
mod_authz_user.so
mod_autoindex.so
mod_cache.so
mod_cern_meta.so
mod_cgid.so
mod_cgi.so
mod_charset_lite.so
mod_dav_fs.so
mod_dav_lock.so
mod_dav.so
mod_dbd.so
mod_deflate.so
mod_dir.so
mod_disk_cache.so
mod_dumpio.so
mod_env.so
mod_expires.so
mod_ext_filter.so
mod_file_cache.so
mod_filter.so
mod_headers.so
mod_ident.so
mod_imagemap.so
mod_include.so
mod_info.so
mod_ldap.so
mod_log_forensic.so
mod_mem_cache.so
mod_mime_magic.so
mod_mime.so
mod_negotiation.so
mod_proxy_ajp.so
mod_proxy_balancer.so
mod_proxy_connect.so
mod_proxy_ftp.so
mod_proxy_http.so
mod_proxy.so
mod_rewrite.so
mod_setenvif.so
mod_speling.so
mod_ssl.so
mod_status.so
mod_substitute.so
mod_suexec.so
mod_unique_id.so
mod_userdir.so
mod_usertrack.so
mod_version.so
mod_vhost_alias.so






Those would be the recompiled versions. Maybe you did not include them
during your build.





Typically it is in:

/etc/apache2/
/etc/httpd

For Apache2 most times httpd.conf is an empty file for legacy and the
actual config is in apache2.conf. Debian breaks up the configuration
into modular configs which I have found very useful, Redhat still puts
everything in one httpd.conf. The source package has template that
should have created the config for your system. The template
httpd.conf.in is in the the tar.gz at httpd-2.2.13/docs/conf I noticed a
mime.types file there that does have text/css defined.

Maybe you should just install the binary package for Solaris

http://archive.apache.org/dist/httpd/binaries/solaris/

It should be already preconfigured with a working default server instead
of rolling your own from the start.

Also the NG more on topic might be alt.apache.configuration...

Thanks Again Jonathan:

I've posted to alt.apache.configuration.

Larry

 

[Jonathan N. Little]

I was addressing specifically the claim that *you* made, not those made by
anyone else.

I also didn't claim that it offered "no advantages". I made no claims one way
or the other about advantages or lack thereof -- I only pointed out that the
disadvantage *you* claimed exists in fact does not.

Well you can "point out" all you want, you can even claim that pigs can
fly, but it doesn't make it true. There are plenty of articles and
evidence for while xhtml may have potential at the current state of the
internet and prevalence of of IE the benefits are not realized and
deployment can be problematic. I just referenced one article that listed
some of the problems.

 

[dorayme]

Doug Miller wrote:

Well you can "point out" all you want, you can even claim that pigs can
fly, ...

I am taking bets on this not being the last pointing out. Our Doug is
very persistent and so you should get good odds betting against it.
Please send all monies to dorayme, c/o Sydney.

 

[Neredbojias]

I was addressing specifically the claim that *you* made, not those
made by anyone else.

I also didn't claim that it offered "no advantages". I made no claims
one way or the other about advantages or lack thereof -- I only
pointed out that the disadvantage *you* claimed exists in fact does
not.

I, too, think it's better to use html than xhtml, and here's one reason
for that.

A bit shy of a year ago I made 2 pages of medium complexity. They were
identical except for the necessary diffs to have one as xhtml and the
other not. Everything was up-to-snuff, valid and all that, and, of
course, the xhtml page was served as application xhtml+xml.

Testing in Firefix indicated that the xhtml page was being parsed by
the xhtml/xml parser, different from the regular html (or sgml) parser.
In any case, there were some standards-compliant problems in the xhtml
page not appearing in the html page and I guarantee they weren't caused
by any markup errors. I couldn't, naturally, try this in ie, and by
the time I thought of experimenting with Opera and Safari, I just
decided to stick with html, anyway.

If what I've read about html5 is true, the xhtml/html disparity will
become almost moot in the future as both will function under the same
"umbrella". -Just my 2 cents worth.

 

[Jonathan N. Little]

I am taking bets on this not being the last pointing out. Our Doug is
very persistent and so you should get good odds betting against it.
Please send all monies to dorayme, c/o Sydney.

Oh I am aware. Hard to counter the debate after "'cuz" assertion, my
comments where more to inform the OP.

 

[Doug Miller]

Well you can "point out" all you want, you can even claim that pigs can
fly, but it doesn't make it true. There are plenty of articles and
evidence for while xhtml may have potential at the current state of the
internet and prevalence of of IE the benefits are not realized and
deployment can be problematic. I just referenced one article that listed
some of the problems.

You continue to miss the point -- which was that my comments were very
narrowly targeted to _one_specific_ erroneous claim which you made.

Apparently you prefer to drag in an entire netful of red herrings, in
preference to admitting that you were mistaken.

Some people are just that way. Too bad for you.

 

[Jonathan N. Little]

You continue to miss the point -- which was that my comments were very
narrowly targeted to _one_specific_ erroneous claim which you made.

Apparently you prefer to drag in an entire netful of red herrings, in
preference to admitting that you were mistaken.

Some people are just that way. Too bad for you.

Enlighten me, and probably anyone else that bothers to continue with
this thread, what _one specific_ erroneous claim?

 

[dorayme]

....
Enlighten me, and probably anyone else that bothers to continue with
this thread, what _one specific_ erroneous claim?

It goes back to your - imo, quite correct - "NO version, not even IE8,
will handle xhtml properly served". You are being baled up for not
acknowledging (and implying the opposite) that it is quite proper to
serve otherwise.

As I see it, Doug Miller may be missing that there is something *less
than quite proper* - even though it is a widespread practice - in
crippling the main intent of XHTML by serving it up as html and that
there is an argument that XHTML as served with a text/html MIME type is
in fact invalid html:

<http://webkit.org/blog/68/understanding-html-xml-and-xhtml/>

Given that there these issues, I want him to be more polite and fair to
you. It's not much to ask on such a hot Sydney avo.

 

[Doug Miller]

It goes back to your - imo, quite correct - "NO version, not even IE8,
will handle xhtml properly served". You are being baled up for not
acknowledging (and implying the opposite) that it is quite proper to
serve otherwise.

That is, indeed, exactly the erroneous claim to which I refer. If in your
opinion that claim is correct, then you also are at odds with the W3C, which
states explicitly -- as I cited in my post -- that XHTML may be properly
served as *either* HTML *or* XML. To claim that it can be properly served
*only* as XML is, quite simply, false.

As I see it, Doug Miller may be missing that there is something *less
than quite proper* - even though it is a widespread practice - in
crippling the main intent of XHTML by serving it up as html and that
there is an argument that XHTML as served with a text/html MIME type is
in fact invalid html:

<http://webkit.org/blog/68/understanding-html-xml-and-xhtml/>

All arguments about which way is better or worse aside, the fact remains that
it is indeed "proper" to serve XHTML as HTML, and anyone who claims otherwise
is misinformed. If you disagree, take it up with the W3C, not with me: I
didn't set the standard. They did.

 

[dorayme]

....

All arguments about which way is better or worse aside, the fact remains that
it is indeed "proper" to serve XHTML as HTML, and anyone who claims otherwise
is misinformed. If you disagree, take it up with the W3C, not with me: I
didn't set the standard. They did.

Ah but you are the one putting all the heavy weight on the word "proper"
which does not appear in the quote you originally offered:

"XHTML 1.0 can be served as HTML or XML. If you serve it as XML, use the
MIME type application/xhtml+xml."

You are deducing that it is a *proper* way to serve it. It is not a word
one would naturally choose when one is pointing out all the downsides
and the various dirty things that happen. It gives too false an
impression of menchy kosherness.

As for me being at odds with the W3C, I doubt I am getting *that* lucky
here, they were not to know what weight someone would put on the word
"proper".

A piece of bacon and a sausage were frying in a pan
when the sausage suddenly exclaimed
"Phew, it's hot in here!". The bacon then said:
"Wow! A sausage that talks!"

 

[Jonathan N. Little]

That is, indeed, exactly the erroneous claim to which I refer. If in your
opinion that claim is correct, then you also are at odds with the W3C, which
states explicitly -- as I cited in my post -- that XHTML may be properly
served as *either* HTML *or* XML. To claim that it can be properly served
*only* as XML is, quite simply, false.

That is where you are wrong. It depends on which version of xhtml, xhtml
1.0 per Appendix C set as html compatible yes, but not xhtml 1.1

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#summary

 

[C A Upsdell]

That is where you are wrong. It depends on which version of xhtml, xhtml
1.0 per Appendix C set as html compatible yes, but not xhtml 1.1

http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#summary

If you read what Doug Miller said earlier, you would have noticed that
he specifically said 1.0. Not 1.1.

 

[Jonathan N. Little]

Jonathan N. Little wrote:

If you read what Doug Miller said earlier, you would have noticed that
he specifically said 1.0. Not 1.1.

He may have but in my initial remarks that he criticized I did not
specify. But it utilize the features of xhtml that would offer and
advantage over html, it needs to be parsed as xml. MathML one example,
but...

 

[Doug Miller]

....


Ah but you are the one putting all the heavy weight on the word "proper"
which does not appear in the quote you originally offered:

"XHTML 1.0 can be served as HTML or XML. If you serve it as XML, use the
MIME type application/xhtml+xml."

You are deducing that it is a *proper* way to serve it. It is not a word
one would naturally choose when one is pointing out all the downsides
and the various dirty things that happen. It gives too false an
impression of menchy kosherness.

As for me being at odds with the W3C, I doubt I am getting *that* lucky
here, they were not to know what weight someone would put on the word
"proper".

Word games. It's very clear that according to the W3C, it's perfectly OK to
serve XHTML as HTML -- contrary to what Jonathon claimed.

 

[Doug Miller]

He may have but in my initial remarks that he criticized I did not
specify. But it utilize the features of xhtml that would offer and
advantage over html, it needs to be parsed as xml. MathML one example,
but...

You made a general statement that XHTML is properly served only as XML. That's
not true.

And that's what I objected to.

 

[dorayme]

Word games.

That is pretty much what I am complaining you are doing. I have said
why.

It's very clear that according to the W3C, it's perfectly OK to
serve XHTML as HTML -- contrary to what Jonathon claimed.

It does not make it clear that it is *perfectly OK*. And no one is
saying it is *perfectly bad* to use xhtml and serve it some way.