From: Garrett S. <g...@rr...> - 2009-07-25 23:16:21
|
In an appmod, the function: out(A) -> {ehtml, {html, [], [{form, [], [{input, [{type,text}]}]} ]}}. is producing the following HTML: <html> <form><input type="text"></input></form></html> I didn't check to see if this is the case in a yaws file. Garrett |
From: Steve V. <vi...@ie...> - 2009-07-26 00:29:58
|
On Sat, Jul 25, 2009 at 7:16 PM, Garrett Smith <g...@rr...> wrote: > In an appmod, the function: > > out(A) -> > {ehtml, > {html, [], > [{form, [], > [{input, [{type,text}]}]} > ]}}. > > is producing the following HTML: > > <html> > <form><input type="text"></input></form></html> > > I didn't check to see if this is the case in a yaws file. Garrett and I had an offline conversation about this because at first I didn't see the issue, but he reminded me that in HTML the input tag officially has no closing tag (sad but true). I don't think it's really a problem in practice, given the huge amount of bad HTML out there that browsers have to compensate for, but we should probably fix this to make Yaws correct in this regard. I'll go ahead and fix it unless someone knows of a good reason not to change it? --steve |
From: Steve V. <vi...@ie...> - 2009-07-28 04:34:34
|
On Sat, Jul 25, 2009 at 8:29 PM, Steve Vinoski <vi...@ie...> wrote: > > Garrett and I had an offline conversation about this because at first I > didn't see the issue, but he reminded me that in HTML the input tag > officially has no closing tag (sad but true). I don't think it's really a > problem in practice, given the huge amount of bad HTML out there that > browsers have to compensate for, but we should probably fix this to make > Yaws correct in this regard. I'll go ahead and fix it unless someone knows > of a good reason not to change it? > Replying to myself, I've gotten some private email stating concerns about changing this, primarily because it would disallow the output from being treated as XHTML or anything else besides strict HTML 4.01. I think that's a valid concern, so perhaps the best course of action really is to just leave it alone. --steve |
From: Robert S. <rob...@er...> - 2009-07-28 05:12:01
|
That is actually not correct! This is what the XHTML spec says on the subject: """ 4.6. Empty Elements Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>. See HTML Compatibility Guidelines <http://www.w3.org/TR/xhtml1/#guidelines> for information on ways to ensure this is backward compatible with HTML 4 user agents. """ HTML Compatibility guidelines """ C.2. Empty Elements Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing user agents. 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 />). """ And from the XHTML DTD (both STRICT and TRANSITIONAL we can see that : """ <!ELEMENT input EMPTY> <!-- form control --> """ So XHTML spec's recommendation is to actually USE <input ... /> with a space before the '/>' to ensure compatibility For HTML 4.01 STRICT an end tag is forbidden and older HTML specs never specified the end tag either Regards /Rob ________________________________ From: Steve Vinoski [mailto:vi...@ie...] Sent: Tuesday, July 28, 2009 12:34 PM To: Garrett Smith Cc: Yaws List Subject: Re: [Erlyaws-list] input tag being closed On Sat, Jul 25, 2009 at 8:29 PM, Steve Vinoski <vi...@ie...> wrote: Garrett and I had an offline conversation about this because at first I didn't see the issue, but he reminded me that in HTML the input tag officially has no closing tag (sad but true). I don't think it's really a problem in practice, given the huge amount of bad HTML out there that browsers have to compensate for, but we should probably fix this to make Yaws correct in this regard. I'll go ahead and fix it unless someone knows of a good reason not to change it? Replying to myself, I've gotten some private email stating concerns about changing this, primarily because it would disallow the output from being treated as XHTML or anything else besides strict HTML 4.01. I think that's a valid concern, so perhaps the best course of action really is to just leave it alone. --steve |
From: Steve V. <vi...@ie...> - 2009-07-28 09:57:21
|
Well, there are specs and then there's actual practice. Believe me, I've read every passage of the specs you've quoted, numerous times. But let's face it -- the most common user agent out there is the browser, and browsers have had to go to great lengths to accept and properly handle really bad HTML, far worse than what we're discussing here, so what Yaws has been producing via ehtml has been good enough to work pretty well in practice. However, this is not to discount Garrett's point or say that it's not worth consideration. He's right that emitting what the specs say is almost always the best way to go, and he's right in his implication that the continued standards work on HTML could impact the ehtml status quo negatively in the future. The concern here is for achieving the best practical compatibility for various HTML versions without breaking ehtml itself or significantly changing it, and without breaking current uses of ehtml. Garrett can attest to the fact that I sent him a prototype patch for this pretty quickly after his original email, but it's the backwards and forward compatibility I'm worried about, which is why I haven't pushed the changes yet. --steve On Tue, Jul 28, 2009 at 1:09 AM, Robert Schmersel < rob...@er...> wrote: > That is actually not correct! This is what the XHTML spec says on the > subject: > > """ > 4.6. Empty Elements > > > Empty elements must either have an end tag or the start tag must end > with />. For instance, <br/> or <hr></hr>. See HTML Compatibility > Guidelines <http://www.w3.org/TR/xhtml1/#guidelines> for information on > ways to ensure this is backward compatible with HTML 4 user agents. > """ > > > HTML Compatibility guidelines > > """ > C.2. Empty Elements > > Include a space before the trailing / and > of empty elements, e.g. <br > />, <hr /> and <img src="karen.jpg" alt="Karen" />. Also, use the > minimized tag syntax for empty elements, e.g. <br />, as the alternative > syntax <br></br> allowed by XML gives uncertain results in many existing > user agents. > > > 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 />). > """ > > And from the XHTML DTD (both STRICT and TRANSITIONAL we can see that : > """ > <!ELEMENT input EMPTY> <!-- form control --> > """ > > So XHTML spec's recommendation is to actually USE <input ... /> with a > space before the '/>' to ensure compatibility > > For HTML 4.01 STRICT an end tag is forbidden and older HTML specs never > specified the end tag either > Regards > /Rob > > > ________________________________ > > From: Steve Vinoski [mailto:vi...@ie...] > Sent: Tuesday, July 28, 2009 12:34 PM > To: Garrett Smith > Cc: Yaws List > Subject: Re: [Erlyaws-list] input tag being closed > > > > > On Sat, Jul 25, 2009 at 8:29 PM, Steve Vinoski <vi...@ie...> wrote: > > > > Garrett and I had an offline conversation about this because at > first I didn't see the issue, but he reminded me that in HTML the input > tag officially has no closing tag (sad but true). I don't think it's > really a problem in practice, given the huge amount of bad HTML out > there that browsers have to compensate for, but we should probably fix > this to make Yaws correct in this regard. I'll go ahead and fix it > unless someone knows of a good reason not to change it? > > > > Replying to myself, I've gotten some private email stating concerns > about changing this, primarily because it would disallow the output from > being treated as XHTML or anything else besides strict HTML 4.01. I > think that's a valid concern, so perhaps the best course of action > really is to just leave it alone. > > --steve > |
From: Garrett S. <g...@rr...> - 2009-07-28 09:21:17
|
I think that not dealing with this properly is a long term problem. We may be close though... If ehtml provided a 'doctype' element, the rendering engine would have an explicit direction on how to format the output. {ehtml, [{doctype, html}, {html, [], hr}]} -> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><hr></html> {ehtml, [{doctype, xhtml}, {html, [], hr}]} -> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><hr/></html> This would take some tweaking, e.g. empty 'div' in HTML is "<div></div>" and in XHTML it's "<div/>", but at least there'd be a way to deal with these issues. We might need a number of doctypes (e.g. http://www.w3schools.com/tags/tag_DOCTYPE.asp), but that list is pretty easy to deal with. Thoughts? On Mon, Jul 27, 2009 at 11:34 PM, Steve Vinoski<vi...@ie...> wrote: > > > On Sat, Jul 25, 2009 at 8:29 PM, Steve Vinoski <vi...@ie...> wrote: >> >> Garrett and I had an offline conversation about this because at first I >> didn't see the issue, but he reminded me that in HTML the input tag >> officially has no closing tag (sad but true). I don't think it's really a >> problem in practice, given the huge amount of bad HTML out there that >> browsers have to compensate for, but we should probably fix this to make >> Yaws correct in this regard. I'll go ahead and fix it unless someone knows >> of a good reason not to change it? > > Replying to myself, I've gotten some private email stating concerns about > changing this, primarily because it would disallow the output from being > treated as XHTML or anything else besides strict HTML 4.01. I think that's a > valid concern, so perhaps the best course of action really is to just leave > it alone. > --steve |
From: Steve V. <vi...@ie...> - 2009-07-28 10:04:17
|
On Tue, Jul 28, 2009 at 5:15 AM, Garrett Smith <g...@rr...> wrote: > I think that not dealing with this properly is a long term problem. I agree, which is why I'm trying to keep the discussion open. We may be close though... > > If ehtml provided a 'doctype' element, the rendering engine would have > an explicit direction on how to format the output. <snip/> This seems like a pretty nice approach. I've been trying to figure out a nice way of effectively versioning ehtml but without breaking current usage, without duplicating a lot of the ehtml handling code in Yaws, and in a way that's understandable and makes sense, and this idea seems to address all these issues nicely. I'll take a stab at incorporating this into the changes I've already made, and we'll see how it looks. thanks, --steve > > On Mon, Jul 27, 2009 at 11:34 PM, Steve Vinoski<vi...@ie...> wrote: > > > > > > On Sat, Jul 25, 2009 at 8:29 PM, Steve Vinoski <vi...@ie...> wrote: > >> > >> Garrett and I had an offline conversation about this because at first I > >> didn't see the issue, but he reminded me that in HTML the input tag > >> officially has no closing tag (sad but true). I don't think it's really > a > >> problem in practice, given the huge amount of bad HTML out there that > >> browsers have to compensate for, but we should probably fix this to make > >> Yaws correct in this regard. I'll go ahead and fix it unless someone > knows > >> of a good reason not to change it? > > > > Replying to myself, I've gotten some private email stating concerns about > > changing this, primarily because it would disallow the output from being > > treated as XHTML or anything else besides strict HTML 4.01. I think > that's a > > valid concern, so perhaps the best course of action really is to just > leave > > it alone. > > --steve > |
From: Edward G. <edw...@ra...> - 2009-07-28 14:27:02
|
On Tue, 2009-07-28 at 06:04 -0400, Steve Vinoski wrote: > > > > On Tue, Jul 28, 2009 at 5:15 AM, Garrett Smith <g...@rr...> wrote: > > > > We may be close though... > > If ehtml provided a 'doctype' element, the rendering engine > would have > an explicit direction on how to format the output. > > > > <snip/> > > > This seems like a pretty nice approach. I've been trying to figure out > a nice way of effectively versioning ehtml but without breaking > current usage, without duplicating a lot of the ehtml handling code in > Yaws, and in a way that's understandable and makes sense, and this > idea seems to address all these issues nicely. [snip] +1 Edward *********************************************************************** This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint. |