Andy Dingley wrote:
> Kidogg wrote:
>
> > Essentially an email template can contain any valid XHTML, but also has
> > tags such as <membershipcardheader> and <membershipcardfooter> that can
> > appear anywhere in the body of the HTML.
>
> HTML email is an abomination, XHTML doubly so.

Justify yourself. Just because we provide HTML email templates does not
mean that they are massively bloated or horrendously formatted. Some of
our clients simply request that they can have some control over the
formatting of their outputted email.

>
> Although the "XHTML route" to adding these elements is obvious (look at
> modularized XHTML) you're heading further and further away from what's
> a realistically usable version of HTML for today's clients. I'd
> strongly recommend that you stick with HTML 4.01 as any "public" use of
> "HTML".

Our webpages are fully XHTML strict compliant and we have no issues -
practically full compatibilty across the board in terms of browsers
(including mobile devices). What issues are you aware of regarding
using XHTML as opposed to 4.01?

>
> There's also a serious question as to why you need to include new tags
> in publically published content. If they're new and unknown, then
> what's the client expected to do with them ?  If they're unusable, why
> include them ?

The point is that they are not included in the final email that is
sent. They are part of a templating system, we have XML email templates
that I wish to validate to stop our clients shooting themselves in the
feet with badly formed XML.

>
> Assuming that they're significant for your in-house CMS, then I'd be
> strongly inclined to use them internally with namespaced XHTML
> (probably just XHTML 1.0 Strict), then strip them out with a final
> "transcode for publication" step, possibly in XSLT, that also converts
> it to HTML 4.01.  This is also a usable route to plaintext email.

Which is what we already do to get our plaintext output. This does not
solve the problem of trying to validate the templates in the first
place however.

>
> PS - send HTML email to me and it goes straight into /dev/null/  You
> _are_ going to support plaintext, aren't you?

Firstly, as above, of course we do, and secondly, you are not
necesarily the typical market demographic for recepients of emails from
our system - just because you prefer plain text does not hold true for
all users.

Regards,
Kieran