Re: [WSG] Strange empty XHTML element issues in IE & FF

[XStandard]

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
**

Re: [WSG] Strange empty XHTML element issues in IE & FF

[Lachlan Hunt]

Vlad Alexander (XStandard) wrote:

Lachlan wrote:
It is just as easy to set , 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:


  
  


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.




  


That list is missing the following empty elements:
* 
* 
* 
* 
* 
* 
* 
* 

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
**

Re: [WSG] Strange empty XHTML element issues in IE & FF

[XStandard]

Lachlan wrote:
> It is just as easy to set , 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

[Lachlan Hunt]

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 , 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
**

Re: [WSG] Strange empty XHTML element issues in IE & FF

[XStandard]

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

[Paul Hempsall]

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 Hempsall]

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

[Nick Gleitzman]

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 
 and 
 need full closing:  and , 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   and not )."


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

[Patrick H. Lauke]

Nick Gleitzman wrote:

Easy. In both cases, 'self-closing' elements is incorrect. Both  
and 
 need full closing:  and , 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   and not )."


http://www.w3.org/TR/xhtml1/#C_3

P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__
**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**