|
|
Posted by cwdjrxyz on 01/13/06 23:43
Marc wrote:
> Thanks for taking the time to write an extensive reply cwdjrxyz, please
> see my comments. :-)
>
> cwdjrxyz wrote:
> > The most important thing is that you use some valid type of html. Even
> > old 3.2 would serve for very simple pages and is still understood by
> > most browsers. However it is quite common for many pages from large
> > corporations to be written in a html soup ranging from html 3.2 to
> > xhtml levels. Some such pages likely were started many years ago and
> > just added to by various people over the years. It is no surprise that
> > some such pages have problems with some common browsers and often fail
> > and must be patched at new browser upgrades.
>
> We always validate our (X)HTML markup and CSS styling, and I'm all to
> aware of the html soup websites you refer to - we're often asked to work
> on websites like this and we usually say that it would be cheaper for us
> to start from scratch and build the website again.
>
> > Concerning xhtml 1.1, it can be used if you make the effort to learn it
> > well. At a minimum, in addition to writing valid html 1.1 code, you
> > must set up your server to serve the page with the mime type of
> > application/xhtml+xml associated with the extension .xhtml, or you can
> > also serve as .xml. If you serve a page written in valid xhtml with the
> > extension .html on most servers, you are just serving the page as html
> > and might as well use 4.01 strict. When you serve true xhtml 1.1 with
> > the proper mime type, you will find that it will be viewed well on the
> > recent Mozilla family browsers(Firefox, Mozilla, and Netscape) and
> > Opera. There are a few bugs in some browsers that can be overcome, such
> > as a CSS body background color one on the Mozilla family browsers.
>
> Regarding serving an XHTML page with a different mimetype, why should we
> do this? Is it because the browsers do not understand the XHTML
> extension? Most of our pages have a .php extension, so what happens in
> these cases - what mimetype would the server pass? How would the
> browser interpret it?
>
> > However, IE6 will not display a true xhtml page served correctly, and
> > rumor has it that neither will the upcoming IE7. You could write a
> > special page for IE in html 4.01 strict as well as the xhtml 1.1 page.
> > However, there is a way around this. The server and browser exchange
> > information when they first connect. The server can ask the browser if
> > it can handle the correct mime type for true xhtml. This is taken care
> > of by a php include at the very top of the page that replaces
> > everything above the head tag of the page, and the page is given an
> > extension of .php .
>
> I understand your logic, but what about when a user has the ability to
> use HTML in a webform which will then be displayed on the website? How
> do you make sure this is valid and inline with the doctype being used?
> Isn't that a bit overkill?
>
> > There can be complications if you use some javascript. For example,
> > document.write is not allowed in xhtml 1.1 and use of it may cause the
> > page not to display or just give an xml error message. The page is
> > parsed as xml when you serve it correctly, and there is no telling what
> > a document.write might generate such as unclosed tags which are fatal
> > for some xml applications. Thus document.write can not be allowed.
> > However this can be overcome by writing some of the script in php on
> > the server which then downloads what the document.write would have
> > generated on the browser, so the xml parser is happy and can check
> > everything for closing tags etc.
>
> Generally we don't use JavaScript, but an exception would be Google
> AdSense banners which give you some JS to incorporate to display the
> banner - again - how do we know that this JS is inline with our doctype?
>
> > I have written well over 100 pages in html 1.1 that are served
> > correctly. Once you have done this several times, it takes very little
> > more time that using html 4.01 strict, so for me it is no longer a big
> > deal. My only advice is that if you use xhtml 1.1, do it right. Else
> > stick with html 4.01 strict.
> >
> > The reason for xhtml is to make PC html code XML pure. There are now
> > many other computing devices, and XML has become the standard for
> > information exchange between them. Xhtml 1.1 greatly improves the XML
> > purity, but it still does not go quite far enough. The higher levels of
> > xhtml in the works will require new browsers.
>
> I've written most of my pages in XHTML 1 Strict or Transitional over the
> last 2 years. I've never noticed any bugs which can be attributed to my
> choice of doctype, but then, maybe I wouldn't notice that...?
>
> > What code you should be using depends on your background and what kind
> > of pages you write. If you work for someone else, the code you should
> > use is what they demand, although some bosses are open to suggestion.
> > If you are your own boss, there are many options. If you are writing
> > general pages to sell things to a wide variety of people, you usually
> > can not get too exotic in the code you use. If you are writing for a
> > network where you can control everything, you can use about any kind of
> > code you wish. And there are many other levels between these two
> > extremes.
>
> I run a small company and one of our services is web development for
> local businesses. We host our own websites, so we have server root
> access and the freedom to do things as we wish.
>
> My main reason for asking was because I'm currently programming a big
> CMS for our use (we won't be distributing it), and it will be one script
> outputting every page, so I wanted to make sure I used the best doctype
> for the job from the start.
>
> Any more info or advice would be much appreciated.
I think the best thing I can do is give you an example of one of my
most complicated pages that was converted to xhtml 1.1 and served as
such. First you must make sure that the server has the mime type
application/xhtml+xml for the extension .xhtml installed - if not you
must install it. This is very easy to do from the control panel for the
Apache Unix server my domain is on - you just type the extension and
mime type into a form there.
First have a look at the old 4.01 strict page at
http://www.cwdjr.net/calendar/perpetual_calendar2.html . When you
examine the code you will find that it uses extensive javascript to
calculate a calendar for the input year and to generate the extensive
CSS for displaying this calculated calendar. This mostly is done with
document.write, and all of this has to go for xhtml 1.1 served
correctly. Instead the calculations and writing the CSS for the
calendar are done on the server using php. Then when the page is
served, all of this finished code that does the same thing as the
result of the javascript code is downloaded to the browser. The browser
can use the xml parser to determine that you are not trying to sneak
some unclosed tags, etc in as might happen if you downloaded a document
..write.
To see the page as served as xhtml 1.1 using the correct mime type,
view http://www.cwdjr.net/calendar2/perpetual_calendar.php . When you
view this page on IE6 or other browsers that can not handle
application/xhtml+xml you will find it is written in html 4.01 strict
so the browser can handle it. When you view the page on a recent
Mozilla family or Opera browser, you will find that it is written in
xhtml 1.1 .But the source code in neither case will show you how this
was done, since php is involved.
To view the actual php code used on the server, see
http://www.cwdjr.net/calendar2/perpetual_calendar.phps . Adding the s
to the php extension allows the code to be displayed as text, while
using a plain .txt file gives a mess on the IE6. But you will see a php
include at the very top of the page. To see the code for this, see
http://www.cwdjr.net/calendar2/mime2.phps . This code is what takes
care of serving the page correctly at the header stage before the
server downloads any actual code to the browser.
If you examine the php code carefully, you can see how php has been
used to replace what is done by document.write on a browser. You will
also see how a form is handled to take the input of the year so that
the php script will know what to calculate and what CSS code to
generate.
This is a very extreme example. In most cases where you do not use
extensive javascript containing many document.writes, your php page on
the server will look about the same as a basic html page with just the
php include at the top of the page to serve things properly.
If you want to verify that the code sent to the browser is correct,
right click while viewing the page, copy, go to the w3c validator, and
paste the code in the text box. If you use the extended interface at
the w3c validator, it will show you what mime type was used to serve
the page. If you take a page, even written in perfect xhtml 1.1 but
with the extension .html, you will find that it is served as just html
and does not have the required application/xhtml+xml mime type. Another
way to tell is to just go to the IE6 browser. If the page displays,
despite your xhtml code, it is just being served as html. If you take a
..xtml extension page that is served properly to IE6 you will find that
it just gives you error messages.
Navigation:
[Reply to this message]
|