From: Rob S. <rob...@en...> - 2003-11-24 09:55:45
Attachments:
mime_type.patch
empty_tags.patch
|
Hi, I found a minor bug: yaws_api:mime_type/1 always returns 'text/plain' This because the generated mimetypes.erl module does not include a '.' in front of the extension, while=20 filename:extension/1 will give you that '.'.=20 Result: there's always a mismatch. Solution: remove the '.' in yaws_api:mime_type/1 (patch file: mime_type.patch) And this I'm not sure about, but it has bitten me with IE: To be politically correct empty elements (ie {tag, attrs}) need to be properly ended with ' />'. However there are some elements (with DTD attribute EMPTY) for which this is not the case (Looking at the code in yaws_api.erl I have the feeling that it is already prepared to handle this). I've included a another small patch to handle this properly. (BTW this can also be worked around by specifying an empty content, causing an end-tag to be created). Oh I did not change this in ehtml_expander (which does not seem to work properly for me, or most likely I don't fully understand how this works). But adding it should be trivial, as it is a similar chnage (patch file: empty_tags.patch). Oh , I'm not subscribed to the list, but I'll check it regularly. /Rob --=20 /----------------------------------------------------------\ | Rob Schmersel | | System Architect | | | | Enea data | | Nytorpsv=E4gen 5B | Tel: +46(0)8-50714314 | | Box 232 | Mob: +46(0)709-714314 | | SE-183 23 T=E4by, Sweden | Fax: +46(0)8-50714040 | \----------------------------------------------------------/ |
From: <kl...@hy...> - 2003-11-24 14:00:07
|
On Mon, Nov 24, 2003 at 10:56:32AM +0100, Rob Schmersel wrote: > Hi, > > I found a minor bug: > yaws_api:mime_type/1 always returns 'text/plain' > This because the generated mimetypes.erl module does not > include a '.' in front of the extension, while > filename:extension/1 will give you that '.'. > Result: there's always a mismatch. > Solution: remove the '.' in yaws_api:mime_type/1 > (patch file: mime_type.patch) > Excellent, applied. > And this I'm not sure about, but it has bitten me with IE: > To be politically correct empty elements (ie {tag, attrs}) > need to be properly ended with ' />'. However there are > some elements (with DTD attribute EMPTY) for which this is > not the case (Looking at the code in yaws_api.erl I have > the feeling that it is already prepared to handle this). > I've included a another small patch to handle this properly. > (BTW this can also be worked around by specifying an empty > content, causing an end-tag to be created). > Oh I did not change this in ehtml_expander (which does not seem > to work properly for me, or most likely I don't fully > understand how this works). But adding it should be trivial, > as it is a similar chnage > (patch file: empty_tags.patch). > This one I don't like that much though. The patch is way to slow to be applied. We can't do lists:member (+ construct a list of lists) for each tag we process. But let's discuss the problem. Are you saying that all bodyless tags that are not in this EMPTY list must be /> terminated ? Looking at the code for ehtml_expand/1 there is now some special treatment for the <img> and the <br> tags, but I think that is more from an aesthetic point. (newlines inserted) Anyway, what exactly is the bug. Is it that for example: expand({input, [{type,submit}]}) generates wrong HTML (without the enclosing </input> and that : expand({input, [{type,submit}],[]}) %% with an epty body is correct. If that is the case, the correct fix would be to insert function clauses like: ehtml_expand({input, Attrs}) -> ehtml_expand({input, Attrs,[]}) -> /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Rob S. <rob...@en...> - 2003-11-25 09:51:37
|
kl...@hy... wrote: > > (patch file: mime_type.patch) > > > > Excellent, applied. Thanks > > > This one I don't like that much though. The patch is way to slow > to be applied. We can't do lists:member (+ construct a list > of lists) for each tag we process. > That's OK, I've only been using Erlang for about 3-4 weeks now and I'm still learning. > But let's discuss the problem. Are you saying that all bodyless > tags that are not in this EMPTY list must be /> terminated ? > No, I was wrong here (I knew I should have researched first, where is my Brown bag ??). The way it should be is that all elements in the list should be terminated with ' />' (note the extra space). > Looking at the code for ehtml_expand/1 there is now some > special treatment for the <img> and the <br> tags, but I think > that is more from an aesthetic point. (newlines inserted) > > Anyway, what exactly is the bug. Is it that for example: > > expand({input, [{type,submit}]}) > > generates wrong HTML (without the enclosing </input> > > and that : > > expand({input, [{type,submit}],[]}) %% with an epty body > > is correct. > > If that is the case, the correct fix would be to insert > function clauses like: > > ehtml_expand({input, Attrs}) -> ehtml_expand({input, Attrs,[]}) -> > No, input is an EMPTY element and should not have an end-tag. The fault occured with : expand({script, [{src, "somescript.js}]}). And actually it is for compliance with XHTML (and not HTML 4.0), but it seems that IE wants this behaviour (it works without the patch in Mozilla). So concluding: In XHTML (and not HTML 4.0x as indicated in the patch) all elements should have a closing tag except EMPTY elements. Those should use a shorthand notation: <tag attrs /> (with a space before the '/' to allow for backward compatibility). Here are some references: http://www.w3.org/TR/xhtml1/#h-4.3 http://www.w3.org/TR/xhtml1/#h-4.6 http://www.w3.org/TR/xhtml1/#guidelines So a better(?) patch might be: %% no end-tag allowed for these elements ehtml_expand({area, Attrs}) -> ["\n<area", ehtml_attrs(Attrs), " />"]; ehtml_expand({base, Attrs}) -> ["\n<base", ehtml_attrs(Attrs), " />"]; ehtml_expand({basefont, Attrs}) -> ["\n<basefont", ehtml_attrs(Attrs), " />"]; ehtml_expand({br, Attrs}) -> ["<br", ehtml_attrs(Attrs), " />"]; ehtml_expand({col, Attrs}) -> ["\n<col", ehtml_attrs(Attrs), " />"]; ehtml_expand({frame, Attrs}) -> ["\n<frame", ehtml_attrs(Attrs), " />"]; ehtml_expand({hr, Attrs}) -> ["\n<hr", ehtml_attrs(Attrs), " />"]; ehtml_expand({img, Attrs}) -> ["<img", ehtml_attrs(Attrs), " />"]; ehtml_expand({input, Attrs}) -> ["\n<input", ehtml_attrs(Attrs), " />"]; ehtml_expand({isindex, Attrs}) -> ["\n<isindex", ehtml_attrs(Attrs), " />"]; ehtml_expand({link, Attrs}) -> ["\n<link", ehtml_attrs(Attrs), " />"]; ehtml_expand({meta, Attrs}) -> ["\n<meta", ehtml_attrs(Attrs), " />"]; ehtml_expand({param, Attrs}) -> ["\n<param", ehtml_attrs(Attrs), " />"]; %% make sure there is an end tag for elements without content ehtml_expand({Tag, Attrs}) -> ehtml_expand({Tag, Attrs,[]}); Tested this with NS 4.76, Mozilla 1.4, IE 5.xx Regards /Rob PS I subscribed to the list now, and the archives are back. |
From: Carsten S. <ca...@gn...> - 2003-11-25 10:25:12
|
Hi Rob, I think it is good, you brought all of this up! On Tue, Nov 25, 2003 at 10:52:23AM +0100, Rob Schmersel wrote: > And actually it is for compliance with XHTML (and not HTML 4.0), but it= =20 > seems that IE wants this behaviour (it works without the patch in=20 > Mozilla). This is a point we should have discussed before: What kind of HTML should we generate? IMO Yaws should make it easy to generate either HTML4 or XHTML conforming code, with HTML4 being the default. Does validator.w3.org accept code produced with your patch as HTML4? Greetings, Carsten --=20 Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers,=20 fingerprint on my home page. |
From: Rob S. <rob...@en...> - 2003-11-25 12:13:15
|
Carsten Schultz wrote: > > Hi Rob, > > I think it is good, you brought all of this up! > > On Tue, Nov 25, 2003 at 10:52:23AM +0100, Rob Schmersel wrote: > > And actually it is for compliance with XHTML (and not HTML 4.0), but it > > seems that IE wants this behaviour (it works without the patch in > > Mozilla). > > This is a point we should have discussed before: What kind of HTML > should we generate? IMO Yaws should make it easy to generate either > HTML4 or XHTML conforming code, with HTML4 being the default. > > Does validator.w3.org accept code produced with your patch as HTML4? > No, it does not. Interestingly it only complains about those elements that belong inside an 'head' element, like 'meta' and 'link'. It does not complain about elements inside a body (e.g. 'br', 'img'). If I try the same html with XHTML 1.0 strict it complains when no end tag (short hand or normal) is included. BTW is there a good way to generate a DOCTYPE using ehtml structure? |
From: <kl...@hy...> - 2003-11-25 12:47:25
|
On Tue, Nov 25, 2003 at 01:13:50PM +0100, Rob Schmersel wrote: > > > Carsten Schultz wrote: > > > > Hi Rob, > > > > I think it is good, you brought all of this up! Agree, > > Does validator.w3.org accept code produced with your patch as HTML4? > > > No, it does not. Interestingly it only complains about those elements that > belong inside an 'head' element, like 'meta' and 'link'. > It does not complain about elements inside a body (e.g. 'br', 'img'). > > If I try the same html with XHTML 1.0 strict it complains when no end tag > (short hand or normal) is included. So what do we want, do we want to be able to generate "different" kinds of HTML and XHTML. Do want the ability to tell ehtml which kind of html we want to generate. Which would be a good way to do that, in the config file ??? In the ~sconf structure ?? > > BTW is there a good way to generate a DOCTYPE using ehtml structure? None that I know of. On an aside note Rob, why did you start to dig into this in the first place, was the any problems for a specific browser with the ehtml that you generated. It was a long time ago I had any such problems, but then again: I've always used: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> And nothing else. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Rob S. <rob...@en...> - 2003-11-25 13:42:37
|
> > So what do we want, do we want to be able to generate "different" > kinds of HTML and XHTML. Do want the ability to tell ehtml which kind of > html we want to generate. > Which would be a good way to do that, in the config file ??? In the ~sconf structure ?? > I personally think it might be good to have a config to indicate the default behaviour and next to that a function (eg. doctype(Doctype) ;) to indicate the coding used in the current document. > > > > BTW is there a good way to generate a DOCTYPE using ehtml structure? > > None that I know of. > > On an aside note Rob, why did you start to dig into this > in the first place, was the any problems for a specific browser > with the ehtml that you generated. > Internet Explorer version 5.xx (who needs standards compliance ??;) did not play nice when I specified several javascripts like: ... {script, [{src, "script1.js"}]}, {script, [{src, "script2,js"}]}, ... This would load the 1st script but fail to load the 2nd script. (and then I thought I remembered correctly how to handle empty content). > It was a long time ago I had any such problems, but then > again: I've always used: > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > > And nothing else. > I actually did not use any DOCTYPE (but that does not seem to matter with IE, it just does not work). /Rob |
From: <kl...@hy...> - 2003-11-25 14:41:29
|
On Tue, Nov 25, 2003 at 02:43:05PM +0100, Rob Schmersel wrote: > I personally think it might be good to have a config to indicate the default > behaviour > and next to that a function (eg. doctype(Doctype) ;) to indicate the coding > used in the > current document. Ok, I'll take a look at that. I like the idea of being able to tell Yaws what ehtml should do. I'll hestitate if it makes ehtml a lot slower though. > > > > > > > BTW is there a good way to generate a DOCTYPE using ehtml structure? > > > > None that I know of. > > > > On an aside note Rob, why did you start to dig into this > > in the first place, was the any problems for a specific browser > > with the ehtml that you generated. > > > Internet Explorer version 5.xx (who needs standards compliance ??;) Haha, The 5.x series of IE are the worst ever. In particular the 5.5 versions ... arghhh /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control |
From: Rob S. <rob...@en...> - 2003-11-26 07:58:34
|
> Ok, I'll take a look at that. I like the idea of being able to > tell Yaws what ehtml should do. I'll hestitate if it makes ehtml > a lot slower though. > Agree. I can live without it, like I said before if I use {Tag, Attrs, []} it works for me. Although it is nice to have this feature. > > > > > Internet Explorer version 5.xx (who needs standards compliance ??;) > > Haha, The 5.x series of IE are the worst ever. In particular the 5.5 > versions ... arghhh > I know, but it is a requirement to support all 'modern' browsers in the windows and Unix world and IE5.xx and upwards is the requirement for windows. I actually still run 5.00.xxx here at work :(, which I never ever use apart from testing and the odd website I can not view with Firebird. /Rob |
From: Marc v. W. <mar...@fe...> - 2003-12-03 02:38:06
|
On Tue, 25 Nov 2003 13:47:21 +0100, <kl...@hy...> wrote: > So what do we want, do we want to be able to generate "different" > kinds of HTML and XHTML. Do want the ability to tell ehtml which kind of > html we want to generate. > It was a long time ago I had any such problems, but then > again: I've always used: > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > > And nothing else. Me too. Anyone noticed a use of XHTML anywhere? I see it as option of the excellent "tidy" tool, which allows me to transform my old HTML stuff to XHTML.. but I really see no reason yet to do so. As far as I understand, XHTML makes HTML valid XML and thus usable for various XML tools. But except for validation I have no further needs so far, and that I can do with tidy. Regards, Marc |
From: Mikael K. <mik...@cr...> - 2003-12-03 09:55:39
|
Wed 03 december 2003 03:37 Marc van Woerkom wrote: > On Tue, 25 Nov 2003 13:47:21 +0100, <kl...@hy...> wrote: > > So what do we want, do we want to be able to generate "different" > > kinds of HTML and XHTML. Do want the ability to tell ehtml which kind of > > html we want to generate. > > > > It was a long time ago I had any such problems, but then > > again: I've always used: > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > > > > And nothing else. > > Me too. > Anyone noticed a use of XHTML anywhere? > .. stuff deleted .. Yes, check out the document sources at www.w3.org, they seem to be "eating their own dogfood". I think XHTML tries to bring HTML back to the original path were you in some sence separate content from presentation (XHTML and Cascading Stylesheets). I vote for XHTML here, or at least the option of beeing able to generate it as well. Other refs: http://www.w3.org/MarkUp/#recommendations Cheers Mikael |