|
Mailing Lists
|
Home /
Groups /
HE3
Default CFM templates and CFDUMP stylesheets
If I create a CFML page using "New->CFML Template" the template gets createdVince Bonfanti 07/28/04 11:17 A > And then CFDUMP works properly. So it seems it's only theMatt Liotta 07/28/04 11:44 A DWMX puts the same line in and causes the same thing to occur with CFDUMP,John Beynon 07/29/04 04:18 A On Thu, 29 Jul 2004 09:16:01 +0100, John Beynon <john.beynon@gmail.com> wrote:Kay Smoljak 07/29/04 10:32 A so MM need to correct CFDUMP?John Beynon 07/29/04 10:34 A > so MM need to correct CFDUMP?Matt Liotta 07/29/04 10:48 A On Thu, 29 Jul 2004 10:45:33 -0400, Matt Liotta <mliotta@r337.com> wrote:Kay Smoljak 07/29/04 08:30 P If I create a CFML page using "New->CFML Template" the template gets created with the following DOCTYPE header: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> With this header, the CFDUMP stylesheets seem to get ignored (at least on BlueDragon). That is, CFDUMP displays without any table borders, background colors, etc. If I remove the DOCTYPE declaration, then CFDUMP works as expected. I notice that HomeSite+ uses a DOCTYPE header of: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> And then CFDUMP works properly. So it seems it's only the "http://www.w3.org/TR/html4/loose.dtd" portion that's causing the problem. Vince > And then CFDUMP works properly. So it seems it's only the > "http://www.w3.org/TR/html4/loose.dtd" portion that's causing the problem. > Without the above string the browser can't retrieve the DTD for HTML 4 transitional and thus can't validate the document. Thus, if the browser has access to the DTD and the document is not displaying as expected then the document is in fact not compliant with the DTD. Check out http://validator.w3.org/ and see how your document does. -Matt DWMX puts the same line in and causes the same thing to occur with CFDUMP, jb. ----- Excess quoted text cut - see Original Post for more ----- On Thu, 29 Jul 2004 09:16:01 +0100, John Beynon <john.beynon@gmail.com> wrote: > DWMX puts the same line in and causes the same thing to occur with CFDUMP, The problem occurs because CFDUMP generates nasty, invalid code - DWMX is trying to follow the standards. An overview of doctype switching in different browsers: http://www.hut.fi/~hsivonen/doctype.html -- Kay Smoljak http://kay.smoljak.com so MM need to correct CFDUMP? On Thu, 29 Jul 2004 22:29:40 +0800, Kay Smoljak <kay.smoljak@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more ----- > so MM need to correct CFDUMP? > Yes, and New Atlanta too. I'd go on to say that all tags that generate HTML should be done in a standard compliant manner. However, there is a problem with that. How would the application server know which HTML standard the CFM page is supposed to produce? For example, if the CFM page is supposed to produce XHTML and CF generates standard compliant HTML; the document still is not standard compliant. Personally, this is the reason why I never use CF tags that generate HTML. BTW, Flash also doesn't produce standard compliant HTML when it generates the HTML would embedding a Flash movie. -Matt On Thu, 29 Jul 2004 10:45:33 -0400, Matt Liotta <mliotta@r337.com> wrote: > How would the application server know which HTML standard the CFM > page is supposed to produce? The only possible way is by specifying.... <cfdump var="#session#" output="xhtml"> But that seems like overkill... maybe Flash *is* the answer! Of course, CFDUMP is for testing purposes only, so it doesn't really matter that the code it produces validates... it just has to display properly in different browsers. I'm fairly sure that if CFDUMP produced standards-compliant HTML 4.01, it *should* display properly in an XHTML 1.0 page. I think. K. -- Kay Smoljak http://kay.smoljak.com
|
May 21, 2013
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||