[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: text/xhtml+xml vs. application/xhtml+xml
> > > But the analogy is gravely flawed in any case -- text/html
> > > has proved to have no value whatsoever. And this goes far
> > > beyond the notion of "good" and "bad" use.
> > I think the millions of messages sent using text/html would
> > disprove the notion that "text/html has proved to have no value
> > whatsoever".
> Actually, the type's use proves nothing, since as I pointed out
> previously, it isn't necessary to use the type to get the
> right effect.
The point is that there is a use driven by a need. Your statement
that "text/html has proved to be of no value whatsoever" is simply
false. The fact is that text/html (while being used in ways other
than strictly intended), has served a tremendous use in allowing
people to exchange richer email messages than text/plain.
> And you are arguing a strawman here. I never said that sending HTML
> was of no use, only that the labelling of it as text/html was and
> is unnecessary.
"unnecessary" != "no value whatsoever"
The community adopted text/html because they weren't presented
with any other mechanism (or at least, the alternatives weren't
presented anywhere nearly as clearly or forcibly). The community
made great use out of it.
> > Anyway, the genie *is* out of the bag.
> For HTML it is. Doesn't mean it is out of the bag for other
> types. We should learn from our mistakes.
I agree. I think *the* mistake (at the MIME level)with HTML
is *not* text/html, but rather one of specification and under
education: text/html could have been registered, and the
specification could have clearly stated that alternatives
existed for use when the amount of markup rendered the message
That said, I would argue that the real mistake is in abusing
HTML in the first place, but that practise is well established
> Because it isn't what we told them to do. We told them to use
> text/html, so that's what they did.
Right. They were not presented with a choice, and *that* is the
> But we also said that the HTML had to be legible. That didn't
Sure, but what else could have happened? Vendors were shoe-horning
HTML support onto existing tools, and there was a marketing need to
get products shipping with support for exchanging HTML content.
> The point is now we know better, so we should not let it happen
I strongly agree with you. That to me means presenting
1) choices for types
2) clear guidelines on their use.
I have faith that when presented with those two things, developers
will do what is right.
> I believe my argument discounts it quite effectively.
Well, belief is a very personal, very subjective thing. I do *not*
believe your argument discounts it at all. Your arguments seem to
me to be an overreaction to something I think we can all agree is
less than perfect.
> In addition, I haven't noticed a lot of support for other
> quarters for your approach.
Perhaps people are just tired of debate and are moving with their
feet? XML 1.0 *has* been around for a long time, and SGML, even
Developers come to the IETF looking for guidance in standards
conformant deployment. In lieu of a standard, a draft will
suffice. In lieu of a draft, rough concensus will suffice.
I think the developer community has largely already made up