From: <je...@de...> - 2005-07-15 22:26:43
|
How can I have ehtml generate <input /> Like <input name=3D"username" type=3D"text" size=3D"12" /> If I try {ehtml, {input, [{name, "username"}, {type, "text"}, {size, "12"}] } } , it generates <input name=3D"username" type=3D"text" size=3D"12"></input> Note, it is the same thing with {ehtml, {hr, [{class, "foobar"}]}} It generates <hr class=3D"foobar"></hr> instead of <hr class=3D"foobar" /> And while I am at it, how to generate something like <hr noshade /> ? TIA for your help, J=E9r=F4me. |
From: Claes W. <kl...@ta...> - 2005-07-17 11:12:47
|
J=E9r=F4me Desquilbet wrote: Hi, >> How can I have ehtml generate >> <input /> >> Like >> <input name=3D"username" type=3D"text" size=3D"12" /> >> If I try >> {ehtml, >> {input, >> [{name, "username"}, {type, "text"}, {size, "12"}] >> } >> } >> , it generates >> <input name=3D"username" type=3D"text" size=3D"12"></input> >> >> Note, it is the same thing with >> {ehtml, {hr, [{class, "foobar"}]}} >> It generates >> <hr class=3D"foobar"></hr> >> instead of >> <hr class=3D"foobar" /> >> This is not possible. Take a look at the code yaws_api:ehtml_expand/1. So what is the semantical difference between <input class=3D"foo"></input> and <input class=3D"foo"/> As far as I know, none, and all browsers should render the two expressions the same ??? right or wrong ?? >> >> And while I am at it, how to generate something like >> <hr noshade /> >> ? Not possible either, the above is not correct xhtml. /klacke |
From: Carsten S. <ca...@co...> - 2005-07-17 11:38:11
|
Hi! Claes Wikstrom schrieb: >=20 > J=C3=A9r=C3=B4me Desquilbet wrote: >=20 >>>How can I have ehtml generate >>> <input /> [...] >=20 > This is not possible. Take a look at the code yaws_api:ehtml_expand/1. > So what is the semantical difference between >=20 > <input class=3D"foo"></input> >=20 > and >=20 > <input class=3D"foo"/> >=20 > As far as I know, none, and all browsers should render > the two expressions the same ??? right or wrong ?? Both may be equivalent XML expressions, I do not know. When it comes to HTML <input class=3D"foo"></input> is incorrect, since 'input' has to be empty. <input class=3D"foo"/> is afaik not even parsable, while <input class=3D"foo" /> is an empty 'input' element with two attributes, one being 'class', the other '/'. This is nearly correct HTML4, the only problem being the attribute '/' that is not in the HTML definition. It should be acceptable in most situations. >>>And while I am at it, how to generate something like >>> <hr noshade /> >>>? >=20 >=20 >=20 > Not possible either, the above is not correct > xhtml. Again, I do not know about XHTML. In HTML, it is just a shorthand for <hr noshade=3D"noshade" /> so the latter could be used. I would however not rely on that being understood by every client. I still do think that it should be possible to use ehtml to generate HTML4 that can be validated. Greetings, Carsten --=20 Carsten Schultz (2:38, 33:47) http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. |
From: <je...@de...> - 2005-07-17 11:35:58
|
Hello, > <input class=3D"foo"></input> >=20 > and >=20 > <input class=3D"foo"/> >=20 > As far as I know, none, and all browsers should render > the two expressions the same ??? right or wrong ?? Yes, you are right, it works. I didn't know that. >>And while I am at it, how to generate something like >> <hr noshade /> >>? >=20 >=20 > Not possible either, the above is not correct > xhtml. Yes, you are right again. The correct expression is <hr noshade=3D"noshade" /> or <hr noshade=3D"noshade"></hr> ;-) Thanks a lot, J=E9r=F4me. |
From: Stefan S. <st...@no...> - 2006-09-16 21:45:18
|
Claes Wikstrom <kl...@ta...> wrote: > Jérôme Desquilbet wrote: >>> How can I have ehtml generate >>> <input /> >>> Like >>> <input name="username" type="text" size="12" /> >>> If I try >>> {ehtml, >>> {input, >>> [{name, "username"}, {type, "text"}, {size, "12"}] >>> } >>> } >>> , it generates >>> <input name="username" type="text" size="12"></input> >>> >>> Note, it is the same thing with >>> {ehtml, {hr, [{class, "foobar"}]}} >>> It generates >>> <hr class="foobar"></hr> >>> instead of >>> <hr class="foobar" /> > > This is not possible. Take a look at the code yaws_api:ehtml_expand/1. 1> yaws_api:ehtml_expand({input}). ["<","input"," />"] 2> yaws_api:ehtml_expand({input, [{name, "foo"}, {value, "bar"}]}). [[], "<", "input", [" name",[61,34,"foo",34]," value",[61,34,"bar",34]], "></", "input", ">"] The empty list in the second call stems from a call to ehtml_nl/1. %% Tags for which we must not add extra white space. ... ehtml_nl(input) -> []; ... Why not make a similar function like ehtml_end_tag/1? ehtml_end_tag(input) -> []; ehtml_end_tag(Tag) -> ["</", atom_to_list(Tag), ">"]; BTW: CL-WHO <http://weitz.de/cl-who/> can be set to a traditional SGML mode instead of XML. Could be a nice idea for yaws' ehtml, too. <http://weitz.de/cl-who/#html-mode> I really don't like XHTML in times where one of the top used browsers doesn't support it. And there's no real benefit. Regards, Stefan -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ |
From: Roberto S. <rs...@gm...> - 2006-09-16 22:40:45
|
Very good point. My ehtml output of my stuff-in-development which is supposed to be HTML (and not XHTML) is currently polluted with closing tags </tagname> where there should be just .... /> > > Why not make a similar function like ehtml_end_tag/1? > > ehtml_end_tag(input) -> []; > > ehtml_end_tag(Tag) -> ["</", atom_to_list(Tag), ">"]; > How is this supposed to be used in a nested ehtml statement ? > > BTW: CL-WHO <http://weitz.de/cl-who/> can be set to a traditional > SGML mode instead of XML. Could be a nice idea for yaws' > ehtml, too. <http://weitz.de/cl-who/#html-mode> > I really don't like XHTML in times where one of the top used > browsers doesn't support it. And there's no real benefit. I also don't like it, because some Javascript frameworks do not play well with XHTML on certain browsers. regards -- Roberto Saccon |
From: Stefan S. <st...@no...> - 2006-09-16 23:28:01
|
Roberto Saccon <rs...@gm...> wrote: > Very good point. My ehtml output of my stuff-in-development which is > supposed to be HTML (and not XHTML) is currently polluted with > closing tags </tagname> where there should be just .... /> >> >> Why not make a similar function like ehtml_end_tag/1? >> >> ehtml_end_tag(input) -> []; >> >> ehtml_end_tag(Tag) -> ["</", atom_to_list(Tag), ">"]; >> > > How is this supposed to be used in a nested ehtml statement ? Changing the following code: ehtml_expand({Tag, Attrs}) -> NL = ehtml_nl(Tag), [NL, "<", atom_to_list(Tag), ehtml_attrs(Attrs), "></", atom_to_list(Tag), ">"]; to ehtml_expand({Tag, Attrs}) -> NL = ehtml_nl(Tag), [NL, "<", atom_to_list(Tag), ehtml_attrs(Attrs), ehtml_end_tag(Tag)]; And my example to ehtml_end_tag(input) -> [">"]; ehtml_end_tag(Tag) -> ["></", atom_to_list(Tag), ">"]; Something like that. Not tested. Just an idea. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ |
From: <ug...@gm...> - 2006-09-20 21:57:28
|
On 9/16/06, Stefan Scholl <st...@no...> wrote: > > Claes Wikstrom <kl...@ta...> wrote: > > J=E9r=F4me Desquilbet wrote: > >>> How can I have ehtml generate > >>> <input /> > >>> Like > >>> <input name="username" type="text" size="12" /> > > > > This is not possible. Take a look at the code yaws_api:ehtml_expand/1. > > > 1> yaws_api:ehtml_expand({input}). > ["<","input"," />"] > 2> yaws_api:ehtml_expand({input, [{name, "foo"}, {value, "bar"}]}). > [[], > "<", > "input", > [" name",[61,34,"foo",34]," value",[61,34,"bar",34]], > "></", > "input", > ">"] > > > The empty list in the second call stems from a call to > ehtml_nl/1. > > %% Tags for which we must not add extra white space. > ... > ehtml_nl(input) -> []; > ... > > Why not make a similar function like ehtml_end_tag/1? > > ehtml_end_tag(input) -> []; > > ehtml_end_tag(Tag) -> ["</", atom_to_list(Tag), ">"]; About a month ago Jeroen van Gelderen mailed this simple patch which has worked perfectly for me http://sourceforge.net/mailarchive/message.php?msg_id=3D36626792 It just does this with ehtml_expand/2: ehtml_expand({Tag, Attrs}) -> NL = ehtml_nl(Tag), [NL, "<", atom_to_list(Tag), ehtml_attrs(Attrs), "/>"]; Claes said he'd fold into the main source, but it seems it didn't make it to 1.65? /tobias |
From: Christian S <ch...@gm...> - 2006-09-17 10:08:22
|
Yaws must[1] make a difference between HTML and XHTML. This must be reflected either in having {ehtml, Tree} and {exhtml, Tree} or have the meaning of 'ehtml' configured sitewide in yaws.conf (which might be a good idea for configuring if pretty-printing with indentation is desired or not). Another option is to introduce .xyaws suffixes to make ehtml spit out XHTML. Please do _not_ turn ehtml into a xhtml producer before anything like the above is done. [1]: IMHO anyway. I am not partial to any markups, but when i chose a w3 doctype to comply with i want to target it 100% and not fall back on tag-soup parser accepting the trailing xml slash for empty elements as suggested from some xhtml appendix. Using the validator is important for me and a timesaver when it comes to creating websites that work across popular browsers on the platforms used today. |
From: Claes W. <kl...@ta...> - 2006-09-17 15:45:05
|
Christian S wrote: > Yaws must[1] make a difference between HTML and XHTML. This must be > reflected either in having {ehtml, Tree} and {exhtml, Tree} or have > the meaning of 'ehtml' configured sitewide in yaws.conf (which might > be a good idea for configuring if pretty-printing with indentation is > desired or not). Another option is to introduce .xyaws suffixes to > make ehtml spit out XHTML. > > Please do _not_ turn ehtml into a xhtml producer before anything like > the above is done. This i almost already done. I do however truly agree that it should be like you say above, where ehtml and then possibly exhtml produce different output. Needs to be done. /klacke |
From: Stefan S. <st...@no...> - 2006-09-17 15:11:23
|
Christian S <ch...@gm...> wrote: > Please do _not_ turn ehtml into a xhtml producer before anything like > the above is done. This thread was started over a year ago. ehtml was a XHTML producer back then and still ist. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ |
From: Claes W. <kl...@ta...> - 2006-09-17 15:46:04
|
Christian S wrote: > Yaws must[1] make a difference between HTML and XHTML. This must be > reflected either in having {ehtml, Tree} and {exhtml, Tree} or have > the meaning of 'ehtml' configured sitewide in yaws.conf (which might > be a good idea for configuring if pretty-printing with indentation is > desired or not). Another option is to introduce .xyaws suffixes to > make ehtml spit out XHTML. > > Please do _not_ turn ehtml into a xhtml producer before anything like > the above is done. This is almost already done. I do however truly agree that it should be like you say above, where ehtml and then possibly exhtml produce different output. Needs to be done, no rocket science, just a bit of legwork. /klacke |
From: Christian S <ch...@gm...> - 2006-09-17 16:07:02
|
On 9/17/06, Claes Wikstrom <kl...@ta...> wrote: > This is almost already done. > > I do however truly agree that it should > be like you say above, where ehtml and then possibly exhtml produce > different output. Needs to be done, no rocket science, just a bit of > legwork. The next step of the discussion is then to pick the solution that steps on minimal amount of toes, or however to put it. Another parameter to the problem is that xhtml should be served under its own mimetype. Except for IE which instead will chew it almost fine with its text/html tagsoup parser. Is *.yaws vs *.xyaws files the best idea, so yaws can differ the mime type automagically? Some sites will likely want to have mixed html and xhtml content. |
From: Claes W. <kl...@ta...> - 2006-09-17 19:15:26
|
Christian S wrote: > On 9/17/06, Claes Wikstrom <kl...@ta...> wrote: >> This is almost already done. >> >> I do however truly agree that it should >> be like you say above, where ehtml and then possibly exhtml produce >> different output. Needs to be done, no rocket science, just a bit of >> legwork. > > The next step of the discussion is then to pick the solution that > steps on minimal amount of toes, or however to put it. > If I was to build a new app/site today - I cannot see one single reason why I would like to ship HTML instead of XHTML today. Can anyone on the list give me a _good_ reason to ship HTML content. A _good_ reason, not a lame reason. /klacke |
From: Stefan S. <st...@no...> - 2006-09-17 21:52:22
|
Claes Wikstrom <kl...@ta...> wrote: > If I was to build a new app/site today - I cannot see one single > reason why I would like to ship HTML instead of XHTML today. > > Can anyone on the list give me a _good_ reason to ship > HTML content. A _good_ reason, not a lame reason. Oh, no, please! No need for another flame war on XHTML. IMHO it's best to give a choice when generating HTML. -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ |
From: Roberto S. <rs...@gm...> - 2006-09-18 03:49:08
|
I believe, the document below lists some good reasons why to ship HTML: http://codinginparadise.org/weblog/2005/08/xhtml-considered-harmful.html On 9/17/06, Claes Wikstrom <kl...@ta...> wrote: > Christian S wrote: > > On 9/17/06, Claes Wikstrom <kl...@ta...> wrote: > >> This is almost already done. > >> > >> I do however truly agree that it should > >> be like you say above, where ehtml and then possibly exhtml produce > >> different output. Needs to be done, no rocket science, just a bit of > >> legwork. > > > > The next step of the discussion is then to pick the solution that > > steps on minimal amount of toes, or however to put it. > > > > > If I was to build a new app/site today - I cannot see one single > reason why I would like to ship HTML instead of XHTML today. > > Can anyone on the list give me a _good_ reason to ship > HTML content. A _good_ reason, not a lame reason. > > /klacke > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > -- Roberto Saccon |
From: <kl...@ta...> - 2006-09-18 07:17:41
|
Roberto Saccon wrote: > I believe, the document below lists some good reasons why to ship HTML: > > http://codinginparadise.org/weblog/2005/08/xhtml-considered-harmful.html Good, I had no idea the topic was this inflamed. Thanks. Thus the solution for yaws is thus to have two separate output modes. HTML and XHTML. Will do. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.tail-f.com -- everything is under control cellphone: +46 70 2097763 |