Re: [WSG] Strange empty XHTML element issues in IE FF
Lachlan wrote: That code [XSLT] your referring too seems to be incomplete. As I mentioned in previous email, it is to illustrate the technique and not meant to be the final script. Lachlan wrote: Fair enough, but do you agree that if there is no intention of any further XML processing, then converting to HTML 4 would be the most appropriate choice? That is a subjective decision on the part of the developer. There is certainly nothing wrong with converting XML to HTML 4 via XSLT server-side to be served to Web browsers. Vlad wrote: Can I assume that you agree that XHTML 1.0 was designed to be backwards compatible to HTML 4 if written to compatibility guidelines? Lachlan wrote: It is clear that that was certainly the intention Therefore XHTML 1.0 was designed to be served as HTML using text/html MIME type. So, can you please, please, please stop making statements like XHTML should not be served as text/html which sound like they are statements of fact whereas they are statements of opinion? Perhaps you can qualify the statements by adding something like In my opinion, it's best to Lachlan wrote: but I don't agree that the HTMLWG were entirely successful in doing so. Not relevant - WWW can be argued as not being entirely successful. Regards, -Vlad http://xstandard.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Strange empty XHTML element issues in IE FF
Title: Message I came across a strange issue last night while converting some XML data via an XSL template into XHTML. Issue 1: In the Head sectionof my XHTML I had an empty script element (see below). IE refused to load the page. FF had no problem with this. script type="text/_javascript_" src=""/ To get IE past this line in the markup I had to change the text to read: script type="text/_javascript_" src=""/script Issue 2: In the body of my document I have an empty div. IE rendered the page correctly. FF didn't close the element, so my CSS didn't get implemented correctly. div class="clear"/ To allow FF to process the div, I had to modify the line to: div class="clear"/div I thought I might need to add a space before the forward slash (ie. div class="clear" /), but this didn't make any difference. What's also weird is that I have plenty of other self-closing elements in the document, but these didn't break the browsers. While the problems have bothbeen resolved, I was just hoping there might be someone more fluent with FF IE's processing of XHTML to explain why this occurred in the first place. Here's the URLs for both pages: http://www.lakemac.com.au/lakemac_final/pageTransformed_broken.html(breaks in IE FF) http://www.lakemac.com.au/lakemac_final/pageTransformed.html(fixed) Best Regards, Paul Hempsall Web Developer Lake Macquarie City Council Phone: (02) 4921-0713 Fax: (02) 4921-0566 Web: http://www.lakemac.com.au This information is intended for the addressee only. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee is prohibited by the sender. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of Council.
Re: [WSG] Strange empty XHTML element issues in IE FF
Lachlan wrote: It is just as easy to set xsl:output method=html, output an HTML4 DOCTYPE and not worry about inserting a space before '/' for empty elements. If you use the 10 lines of re-usable code that I suggested in your XSLT, one does not need to worry - you have XML in and you have XML out. If you're using XSLT, why bother attempting to comply... It depends on your requirements - right? If you are doing a batch process and you plan to store the output before serving it, you would want to store it in a parsable form that can be served as is or further processed by other XML technologies. Can I assume that you agree that XHTML 1.0 was designed to be backwards compatible to HTML 4 if written to compatibility guidelines? Regards, -Vlad http://xstandard.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
Vlad Alexander (XStandard) wrote: Lachlan wrote: It is just as easy to set xsl:output method=html, output an HTML4 DOCTYPE and not worry about inserting a space before '/' for empty elements. If you use the 10 lines of re-usable code that I suggested in your XSLT, one does not need to worry - you have XML in and you have XML out. That code your referring too seems to be incomplete. It doesn't handle every empty element, and in fact seems to explicitly filter out link and meta elements, along with script and iframe elements which makes no sense to me. Excerpt from the XSLT: xsl:template match=* xsl:variable name=lcase-elt-namexsl:value-of select=translate(name(), $ucase, $lcase)//xsl:variable xsl:if test=$lcase-elt-name != 'script' and $lcase-elt-name != 'meta' and $lcase-elt-name != 'link' and $lcase-elt-name != 'iframe' Why do that? AFAICT, this prevents those elements from being output. There may be a reason for that in your specific application, but it doesn't really make this code reusable as is, without modification. xsl:choose xsl:when test=$lcase-elt-name = 'br' or $lcase-elt-name = 'hr' or $lcase-elt-name = 'base' or $lcase-elt-name = 'img' or $lcase-elt-name = 'input' That list is missing the following empty elements: * link / * meta / * basefont / * isindex / * area / * col / * frame / * param / As a result, I believe (with the exception of link and meta) these will be processed as non-empty elements by your code, and thus not comply with Appendix C. If you're using XSLT, why bother attempting to comply... It depends on your requirements - right? Yes, it does. If you are doing a batch process and you plan to store the output before serving it, you would want to store it in a parsable form that can be served as is or further processed by other XML technologies. Fair enough, but do you agree that if there is no intention of any further XML processing, then converting to HTML 4 would be the most appropriate choice? Can I assume that you agree that XHTML 1.0 was designed to be backwards compatible to HTML 4 if written to compatibility guidelines? It is clear that that was certainly the intention, but I don't agree that the HTMLWG were entirely successful in doing so. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] Strange empty XHTML element issues in IE FF
Title: Message I came across a strange issue last night while converting some XML data via an XSL template into XHTML. Issue 1: In the Head sectionof my XHTML I had an empty script element (see below). IE refused to load the page. FF had no problem with this. script type="text/_javascript_" src=""/ To get IE past this line in the markup I had to change the text to read: script type="text/_javascript_" src=""/script Issue 2: In the body of my document I have an empty div. IE rendered the page correctly. FF didn't close the element, so my CSS didn't get implemented correctly. div class="clear"/ To allow FF to process the div, I had to modify the line to: div class="clear"/div I thought I might need to add a space before the forward slash (ie. div class="clear" /), but this didn't make any difference. What's also weird is that I have plenty of other self-closing elements in the document, but these didn't break the browsers. While the problems have bothbeen resolved, I was just hoping there might be someone more fluent with FF IE's processing of XHTML to explain why this occurred in the first place. Here's the URLs for both pages: http://www.lakemac.com.au/lakemac_final/pageTransformed_broken.html(breaks in IE FF) http://www.lakemac.com.au/lakemac_final/pageTransformed.html(fixed) Best Regards, Paul Hempsall Web Developer Lake Macquarie City Council Phone: (02) 4921-0713 Fax: (02) 4921-0566 Web: http://www.lakemac.com.au This information is intended for the addressee only. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee is prohibited by the sender. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of Council.
Re: [WSG] Strange empty XHTML element issues in IE FF
Hello Paul, On 22 Feb 2006 at 9:16, Paul Hempsall wrote: I came across a strange issue last night while converting some XML data via an XSL template into XHTML. yes, there are some problems. I had the same problems creating output pages inside my main project 'server-daten'. Users can create Html- pages with sd-elements (sd:table ... etc). Calling such a page it is transformed with XSL and some informations from a database. So the database-content can be shown as Html without using PHP/Perl. The best bug: Create an empty Html - title in the source. XSLT creates: title / FF / Opera - all best. IE6 shows nothing, but shows the correct code. Two samples: http://beispiel.server-daten.de/output-title.html http://beispiel.server-daten.de/output-title-empty.html Additional problem: Creating an empty a and adding the link later with JavaScript. Didn't work, solution: Add a comment as content of the a. a!--d--/a Regards Juergen Auer Jürgen Auer, http://www.sql-und-xml.de/ Web-Datenbanken zum Mieten Friedenstr. 37, 10 249 Berlin Tel.: (030) 420 20 060 Fax: (030) 420 19 819 [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
On 22 Feb 2006, at 9:16 AM, Paul Hempsall wrote: Issue 1: In the Head section of my XHTML I had an empty script element (see below). IE refused to load the page. FF had no problem with this. script type=text/javascript src=nav.js/ To get IE past this line in the markup I had to change the text to read: script type=text/javascript src=nav.js/script Issue 2: In the body of my document I have an empty div. IE rendered the page correctly. FF didn't close the element, so my CSS didn't get implemented correctly. div class=clear/ To allow FF to process the div, I had to modify the line to: div class=clear/div Easy. In both cases, 'self-closing' elements is incorrect. Both script and div need full closing: /script and /div, whether they're empty or not. HTH N ___ Omnivision. Websight. http://www.omnivision.com.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
Paul Hempsall wrote: I came across a strange issue last night while converting some XML data via an XSL template into XHTML. Issue 1: In the Head section of my XHTML I had an empty script element (see below). IE refused to load the page. IE does not support XHTML at all. All of your problems are a result of using the wrong MIME type. XHTML should not be served as text/html, it should be served as application/xhtml+xml or other XML MIME type. When you serve XHTML as text/html, browsers think they are receiving HTML, so that's how they parse it. They have to resort to error handling techniques to handle all those extra slashes and, in this case, missing end tags. The following explanations of your problems only relate to text/html documents. The syntax is perfectly well-formed XML, but requires an XML MIME type to be parsed properly. FF had no problem with this. script type=text/javascript src=nav.js/ The reason Firefox appears to have no problem with it is because of the way it will reparse the entire document from that erroneous script element when it hits EOF and has not found a matching /script end-tag. This behaviour cannot be relied upon, or any other markup that currently causes Firefox to reparse it, as this will likely change in the not-too-distant-future. As far as browsers are concerned, that is exactly equivalent to: script type=text/javascript src=nav.js If you remove the '/' from your document, you will get exactly the same result. Compare these: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript/%3E%0A%3Cp%3Efoo http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cscript%3E%0A%3Cp%3Efoo%0A%3Cscript%3E%3C/script%3E To get IE past this line in the markup I had to change the text to read: script type=text/javascript src=nav.js/script That is the correct what to handle it. Issue 2: In the body of my document I have an empty div. IE rendered the page correctly. FF didn't close the element, so my CSS didn't get implemented correctly. div class=clear/ Again, that is exactly equivalent to: div class=clear, with no end-tag. See what the DOM looks like: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cdiv/%3E%0A%3Cp%3Efoo To allow FF to process the div, I had to modify the line to: div class=clear/div That is correct. I thought I might need to add a space before the forward slash (ie. div class=clear /), but this didn't make any difference. The space is required for compatibility with some older browsers (Netscape 4.x I think), so that they don't completely choke on it. What's also weird is that I have plenty of other self-closing elements in the document, but these didn't break the browsers. It's ok to do it with empty elements like link /, meta /, br /, etc. because they're already EMPTY in HTML and don't require end tags. In such cases, the '/' is just handled as part of error recovery, the browser doesn't keep looking for an associated end tag. The same is not true for elements that aren't EMPTY in HTML. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
On 22 Feb 2006, at 10:00 AM, Patrick H. Lauke wrote: Nick Gleitzman wrote: Easy. In both cases, 'self-closing' elements is incorrect. Both script and div need full closing: /script and /div, whether they're empty or not. To expand on that answer: unless you're sending XHTML with an XML or XHTML+XML MIME type, you must follow the compatibility guidelines under Appendix C of the XHTML 1.0 spec. This particular case is covered under C.3... C.3 Element Minimization and Empty Element Content Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use p /p and not p /). http://www.w3.org/TR/xhtml1/#C_3 P Thanks, Patrick and Lachlan, for that clarification. I was so distracted by trying to make out Paul's miniscule font size that I didn't read his first line properly... N ___ Omnivision. Websight. http://www.omnivision.com.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Strange empty XHTML element issues in IE FF
Thanks for everyone's responses - a wealth of information, as usual. Nick: I'm using plain text now for my emails, I apologise for the inconvenience. PaulH This information is intended for the addressee only. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee is prohibited by the sender. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of Council. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Strange empty XHTML element issues in IE FF
Just a followup - in case anyone else was following this thread. I found a really informative page that expands on the answers provided on this list: http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html I've also discovered (after trying to figure out why the W3C Validator kept saying my MIME type was text/html) that you need to ensure that the server has it's MIME types setup properly so that the document is delivered to the client as application/xhtml+xml. PaulH This information is intended for the addressee only. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee is prohibited by the sender. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of Council. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
Paul wrote: I came across a strange issue last night while converting some XML data via an XSL template into XHTML. You can write your XSLT to output XHTML that follows compatibility guidelines. You can use the technique in this XSLT: http://misc.xstandard.com/wsg/preview.zip If you need a hand with your XSLT, contact me off the list and I'll be happy to help. Lachlan wrote: XHTML should not be served as text/html Please, give it a rest. XHTML was designed to be backwards compatible, so it can be served as HTML if written to compatibility guidelines; unless you know something that the W3C XHTML working group doesn't. Regards, -Vlad http://xstandard.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Strange empty XHTML element issues in IE FF
Vlad Alexander (XStandard) wrote: You can write your XSLT to output XHTML that follows compatibility guidelines. You can use the technique in this XSLT: http://misc.xstandard.com/wsg/preview.zip If you need a hand with your XSLT, contact me off the list and I'll be happy to help. If you're using XSLT, why bother attempting to comply with the oft criticised, self-contradictory, *non-normative* Appendix C? (I will not get into another flame war over this, I just want to know your reasons, assuming you actually have any.) It is just as easy to set xsl:output method=html, output an HTML4 DOCTYPE and not worry about inserting a space before '/' for empty elements. There is no benefit to be gained from serving XHTML as text/html to the client, even if there are benefits gained from working with XHTML on the server side. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
