Re: XHTML and "big" features was Re: [PHPiCalendar-DEV] $_GET variables

[Ed <co...@fu...>]

On Friday, November 22, 2002, at 07:35  PM, Patrick Berry wrote:
> Before we go down this road, you might want to take a peek at:
>
> Sending XHTML as text/html Considered Harmful
> http://www.hixie.ch/advocacy/xhtml

I've read this before, and I think the guy is strongly overstating the=20=

point.  This might have been accurate 2 years ago, but nowadays it's=20
very hard to run across a user agent that doesn't handle XHTML1.0=20
Transitional properly.  He's not wrong, per se... I think his points=20
are just not relevant in the vast majority of cases.  Much of his=20
argument boils down to support of legacy and non-pc user agents, which=20=

is ironic since XHTML's XML nature in fact allows you to more elegantly=20=

solve that problem than HTML4.01 can.

I've recently redone a major InfoSec site in XHTML and CSS, and have=20
yet to run into any of the problems he mentions, despite the fact that=20=

I'm supporting browsers as old as NS4.

> A Warning to Others
> http://diveintomark.org/archives/2002/11/21.html#a_warning_to_others
> Someday, I=92ll upgrade myself from =93SHOULD NOT chase after bleeding=20=

> edge technologies that don=92t solve real world problems=94 to =93MUST =
NOT=20
> chase after bleeding edge technologies that don=92t solve real world=20=

> problems=94.

The big reason to use XHTML is its XML nature... not (imho) because of=20=

anything the language adds over HTML.  Those XML-inherent properties=20
that intersted me the most included the cleaner syntax and the ability=20=

to transform between schema.  Those definitely *do* solve real world=20
problems.  If they're not issues for you, though, it's certainly going=20=

to be of less use.

> One of the things that immediately attracted my to phpiCalendar was=20
> the 'drop it in, and it works' installation.  There has been lots of=20=

> talk of grander features, and I'm wondering if a potential fork of the=20=

> code would be prudent to make sure they ease of install is always=20
> there.  If all the easy can be contained in the prefs, there should be=20=

> no need to fork off into a "lite" version.  A fork would be a pain for=20=

> many, many reasons, I know.  Just tossing stuff out...imagine putting=20=

> in support for Smarty templates or databases.

I don't think the additional features should hurt the ease of install=20
as long as the default settings don't enable things that require more=20
work (like database setup).  For example, phpBB2 includes a very=20
full-featured template/theme system, but it's clear that the majority=20
of installers don't make any use of it.  I'm definitely glad it's=20
there, though.

I've done some experiments with replacing the embedded markup that=20
currently exists in PHPiCalendar with an existing templating system,=20
and it went pretty well.  Templating would also be a good way to make=20
everyone happier regarding HTML vs XHTML -- you can just role your own=20=

templates without interfering with the main codebase.

--
"it's like an addiction to idiocy" -j
-Ed