Why XHTML?

jsumners

This is something I've wondered about ZenPhoto for a long time. I thought about bringing it up when i read bug #391, but decided to ignore it. But I just had a conversation about the same topic in a different scenario, and it got me to thinking about ZenPhoto again. So, I want to ask why ZenPhoto generates XHMTL instead of HTML?

Before answering, take the time to read http://hixie.ch/advocacy/xhtml, and the Surfin' Safari article on the same topic. I agree with the conclusions of those articles. I think that unless you have a specific reason to target XHTML, you should be writing HTML 4.01 markup. In fact, I write all of my HTML to the 4.01 Strict DTD.

trisweb

Those were some very good reads, I very much agree with the idea that one shouldn't use the newest technology just because it's there.

When I wrote Zenphoto originally it was my habit to write (and serve) true xhtml documents -- it went with the mantra at the time, of standards-based XHTML+CSS content+design (which is of course still good with HTML). I had fully intended to make Zenphoto XML-compatible for many of the advantageous reasons, but of course none of that panned out because of various reasons, mainly Internet Explorer.

It still pains me that we're reduced to not using a valid XML format simply because Internet Explorer cannot handle application/xhtml+xml. By no fault of its own of course, it's just an older browser, but we have to deal with so much incompatible crap because of it that one more thing just drives me up the wall.

But, given that the intended use of Zenphoto is to render in a browser, and not be parsed by some XML system, I agree that HTML is the way to render it. My philosophy before was sort of "If internet explorer didn't exist, and we were moving forward, what would be the best format?" and of course XHTML makes perfect sense in a world that supports it fully. It is by nature a more general, abstract, and useful format from a developer's standpoint.

Frankly I entirely disagree with the sentiment that people are using the XHTML 1.0 doctype for "no good reason" - I mean, that at least gives you stricter validation from the W3C, and people are then more likely to have good code that's mostly compatible with DOM traversal etc., more likely to use CSS for layout, more likely to pay attention to their (X)HTML code, and thank God for the deprecated tags! Good riddance to ``, especially, and if that's the only thing to come of it, then that's good enough for me.

The argument is simply that we should use an older HTML spec because a) it's correct for what we're rendering, and b) it's easier to make it right (escaping `` problems, etc., and c) works better for older browsers.

So, I agree with you, we do not have a specific reason. But I am also not convinced that using the newer spec is in all ways worse, because I like XML in general and the idea that HTML can be defined in terms of this broader more flexible markup is very cool and general and certainly not worth nothing. And even though that is a future ideal that isn't terribly useful right now, it also works in the real world as-is, so why not use it and help the 'tag soup' approach a more generalized standard?

acrylian

Originally XHTML should become the successor of HTML 4, but now that the W3 sort of officially abandoned that in favor to HTML 5 (whenever this might be ready) this might be seen as another reason to use HTML again.

BTW, hopefully someone saves us from Microsoft's idea of version targeting...

jsumners

"Frankly I entirely disagree with the sentiment that people are using the XHTML 1.0 doctype for "no good reason" - I mean, that at least gives you stricter validation from the W3C, and people are then more likely to have good code that's mostly compatible with DOM traversal etc., more likely to use CSS for layout, more likely to pay attention to their (X)HTML code, and thank God for the deprecated tags! Good riddance to <font>, especially, and if that's the only thing to come of it, then that's good enough for me."

Using the XHTML 1.0 doctype doesn't necessarily give you stricter validation. That entirely depends on the DTD you target. You recently changed ZenPhoto's target from Strict to Transitional XHTML. You did it for a couple of reasons, but the most applicable to this discussion is that ZenPhoto's "Strict" XHTML was definitely not strict. You can get just as strict validation by writing HTML 4.01 Strict markup. The same elements that are deprecated in XHTML 1.0 are deprecated in HTML 4.01 Strict.

Personally, I think ZenPhoto shouldn't return any markup at all to the template engine. In this case, just PHP mixed with markup that calls some "template" functions. I think that only data should be sent to the template. The template author can then decide which markup style he prefers. As it is now, if I were to write a ZenPhoto theme from scratch I would have to write an XHTML Transitional document. I have no choice of using HTML 4.01 Strict because there will be some markup inserted into the template that I didn't write.

As for HTML 5. I haven't kept up with it. I've been busy with mathematics. But completely abstracting the data from the presentation makes it a moot point.

acrylian

Personally, I think ZenPhoto shouldn't return any markup at all to the template engine. In this case, just PHP mixed with markup that calls some "template" functions. I think that only data should be sent to the template.

Some functions do return combined things like printPageListWithNav, that would get a lot more complicated for the normal user. But generally I agree that the template functions should return as less markup as possible.

jsumners

I don't see what the "normal user" has to do with it. The only person that would be concerned with it is the template designer. I bet if you took a poll, most of them would prefer to have only the data. It allows them a lot more freedom with their design.

Let's look at the specific case you brought up. Here is ZenPhoto's nav list function:

`function printPageListWithNav($prevtext, $nexttext, $oneImagePage=false, $nextprev=true, $class='pagelist', $id=NULL) {

$total = getTotalPages($oneImagePage);

if ($total < 2) {

$class .= ' disabled_nav';

}

echo "

";

$current = getCurrentPage();

echo "n

";
if ($nextprev) {
echo "n
• ";
  
  printPrevPageLink($prevtext, "Previous Page");
  
  echo "";
  
  }
  
  for ($i=($j=max(1, min($current-2, $total-6))); $i <= min($total, $j+6); $i++) {<br />
  echo "n
• ";
  
  printLink(getPageURL_($i, $total), $i, "Page $i" . (($i == $current) ? " (Current Page)" : ""));
  
  echo "";
  
  }
  
  if ($i <= $total) {echo "n<br />
  
• " . ". . ." . "
"; }
if ($nextprev) {
echo "n
• ";
  
  printNextPageLink($nexttext, "Next Page");
  
  echo "";
  
  }
  
  echo "n";
  
  echo "n

n";

}`

Here is the code that generates the navigation data on my personal site:

`/* Previous page. */

( $page > 1 ) ? $smarty->assign('prev', 'true') : $smarty->assign('prev', 'false');

if ( $total_pages != 0 ) {

/* Numbered links. */

for ( $i = 0; $i < $total_pages; $i++ ) {

$nav[$i] = $i + 1;

}

} else {

$nav = NULL;

}

/* Next page. */

( $page < $total_pages ) ? $smarty->assign('next', 'true') : $smarty->assign('next', 'false');

$smarty->assign('page', $page);

$smarty->assign('nav', $nav);`

Which, as a designer, would you rather have? The pre-formatted list that locks you into a design? Or the array of numbers? Agreed, they will most often be placed into a list and styled with CSS, but someone might have a different approach.
`

aitf311

jsumners, if you wanted to start pulling the template code out of the function and put it back into the theme I'm sure no one would have a problem with that. It's a delicate balance but when the choice is made to put the template code into a function instead of the theme page, the function always accepts id and/or class names for theme reasons.

jsumners

I haven't the time to overhaul how ZenPhoto's theming works right now. I'm able to contribute small patches during the little free time that I have right now, but something like that would take much more time than I can currently devote. The whole code base would have to be converted at once. If it were done little by little then third party themes would constantly be breaking. One huge conversion means everyone's themes would break, but they would only have to fix them once.

Yes, the current method of accepting custom themes and ids is a good approach for the theming as it is. But it still limits the designer to using the markup generated by the software. Which in turn limits the designer to the document type that the software targets (XHTML 1.0). Which we have already established is not relevant to the way ZenPhoto works right now.

I am merely suggesting that if it is decided to switch to HTML instead of HTML, completely abstracting the data from the presentation should be seriously considered. It would make any future doctype changes much easier.

acrylian

Just to come back shortly: Regarding the flexibility of the printPagesListWithNav() (to stay on that example) to design, we have all the functions of these combined functions in separate versions, too.
But again I agree that the <span>-markup in printPrevPageLink() for example is not really necessary and could be also added in the normal template html.

jsumners

Okay, but that means there is a lot of redundant code that has to be maintained. All of that redundant code is also loaded every time the script is run. So by removing the markup from the source code you are not only making the source code easier to maintain, you are also making the program a little faster.

sbillard

Jsummers:

Your argument seems to be that theme designers want to write all the code out to do their page. I doubt that is a universal desire. Even your example above decries this view. You have just created a "different" version of the support for printing pages--your 'smarty' object.

Personally, I'd rather have what makes my job easier. In some cases that is the underlying structure, in others it is the pre-canned output.

jsumners

I suppose you can look at it that way, and in this case it is very much like that. On my site I use Smarty as a simple templating engine with caching support. There is very little "code" in my presentation templates. I let Smarty take care of merging my HTML with my PHP. So, my "index.php" contains nothing but PHP and allows me to concentrate specifically on the code. My "index.php" decides what data to pull from the database, assigns some template variables, and then sends control to the template engine.

But you're right. As ZenPhoto is now, that templating "engine" would be the template author dealing with all the data himself. If I were to branch ZenPhoto myself to implement the changes discussed in this thread, I would probably incorporate Smarty.

Take a look at http://www.smarty.net/rightforme.php and http://www.smarty.net/crashcourse.php. I think you'll have a better understanding of what I am trying to say. Of particular note, this is from the second link:

"As you can see, Smarty cleanly separates your presentation elements (HTML, CSS, etc.) from your application code. However, it does not necessarily separate logic entirely from your templates. With respect to Smarty's design principles, so long as the logic in the templates is for presentation only, it is permissible to use it. For instance, looping over table row colors or including one template from another would be considered presentation logic. This is something the application should not need to accomodate (it just supplies an array of data.) The idea is to keep the template designer role and application programming role separated. You should be able to completely tear down the templates and rebuild them without touching the code base, all while retaining full control of the presentation."

I think that states my position much better than I have been. Hopefully you can see how that would make your job easier overall.

trisweb

jsumners, you're completely correct, and if I rewrote zenphoto that's exactly what I'd do.

"I haven't the time to overhaul how ZenPhoto's theming works right now." -- that's exactly why we haven't done it either. We're very much operating on a real-world working basis. The template functions were designed to output HTML and make creating a simple theme as fast and easy as possible at the time. Because I was starting from scratch, a lot of that ended up being abstraction of repeated HTML code, and thence was zenphoto born. More of my attention was focused on the image processing, data modeling, and administration aspects -- indeed the whole idea of themes was just to load a different set of PHP views based on a folder name. The theme engine was built this way because it was the simplest that worked, not because it was the correct or most elegant way. And it works for 99% of cases, and in those where it doesn't, Zenphoto's model is also flexible enough to only output data. If it makes more sense from an MVC standpoint, the template functions are helper functions for an HTML view layer. You could just as easily create a smarty template engine for zenphoto, or whatever else. Just replace template-functions.php with the view layer framework you want to use instead, or none if you please and keep all your view code in your views, but that would be equally messy.

It's not 100% correct and it's not always pretty but it works in nearly all of the cases Zenphoto is designed to support, and in cases where something else is required, it's still easy to get at the data. I think this is elegant in its simplicity and understandability and usefulness for its intended purpose.

I'm beginning to agree with you on converting to HTML 4.01 Strict, but I'm still a pragmatist and if XHTML 1.0 is working (which it is, without any complaints from the real world yet, afaik) then I don't see a reason to divert coding time to address the issue quite yet. I do see your point very clearly though, and if you want to do it you are certainly welcome to.

And, for the love of God, don't branch Zenphoto. It is a three-year-old project with a lot of built-up cruft and any good programmer knows you're better off starting from scratch at that point. If you would like to begin on Zenphoto 2.0 then we have some talking to do. ;-)

jsumners

Glad someone sees my point

I understand where Zenphoto has come from, and I understand how a project can snowball to a point where fixing it is a headache. That's why you don't see me saying "this must be done now!" But if the code base really is going to be overhauled, and I've seen indications that it might be, then I want to get this topic on people's minds. That would be an excellent time to implement the changes.

I don't mean "branch" as in take the current code and start a new project with a new name. I mean take a current snapshot of the code, implement the changes, and submit it for possible merging with trunk. (As an aside, you'll probably find this article interesting.)

I might begin on Zenphoto 2.0 or whatever you want to call it after this semester. That's only ten weeks away. But right now, I have to focus on my senior project. I've actually been wasting precious time by browsing this site when I should be doing research I also have to see how busy summer semester will be; I'm thinking not very.

sbillard

What any good software company knows is that you can never "catch up" when rewriting an application. That's because unless you freeze the current one, the target is a moving one. And, if you freeze the current one, then people stop using it, so there is no reason to replace it.

trisweb

j - I've read that article, Joel makes some very good points as usual, but there's a point where major architectural decisions trump code re-use. That's how Zenphoto got started in the first place. My idea was originally to branch Photostack, but their "object-oriented" model contained two classes - a "Photostack" and an "Organize" - for the gallery and admin functions respectively. No OOP benefits to that and not much code re-use possible (especially as the rest of the architecture was of similar caliber).

I would of course use a *lot* of current Zenphoto code if we were to start developing ZP 2.0. The current zenphoto is built fairly well and has a great generic persistence framework that can be extended easily. For ZP 2.0 it's mainly refactoring and re-thinking that I'm talking about, so I think we both seem to have the right idea.

@stephen - It depends on how bad the original software is and how hard it has become to develop new features after 10-20 years of buildup ;-) I'm currently working on a scratch re-write of a major enterprise package (day job) and we've "caught up" and then some in a matter of months using new and better technologies that make development and maintenance orders of magnitude faster. The idea is to work on making the development process fast and efficient, then everything gets better real fast.

So while Joel is correct about code re-use in most situations, there are always exceptions. Or competitor's software is on top of a 15-year-old package built for aerospace engineering, they moved markets entirely, and hacked on new parts on top of the old technology just so they could go fast in the initial market. But now huge companies are suing them because the software can't do what they advertise; they simply can't make it scale or do anything efficiently. This is a case where a full re-write would have made enough sense, but it didn't make economic sense because they still have zero competition and probably wouldn't be able to catch up anyway. So we're doing it for them. So, I do not agree that rewriting from scratch is *never* a good idea -- I think that a good software company would not be afraid of doing that if it made sense economically, but that would be a very rare situation ineed.

Zenphoto is not in this situation. We've got a good codebase and a good foundation, so we'll be able to use a lot of it in refactoring with some new ideas as they come. Let's get there gradually though, 1.2, 1.3, 1.4, and then we'll think about 2.0 once we see how far we've come.

And, James, you going to join our development team already? ;-)

jsumners

I'm up for joining if the team feels they want, or need, me. I like ZP, and had plans to continue its development on my own if it hadn't picked back up before I graduated. Of course, we know that has happened and I'm back to submitting patches. ZP is almost exactly what I thought I would have to write myself when I started looking for gallery software.

trisweb

Cool! Well keep up the good work for now, I'll get the opinions of the other team members and see what happens.

optimiced

I don't find anything wrong with XHTML 1.0 Transitional. Some people use HTML 4.01, others - XHTML 1.0. But I think most of today's websites are built using the XHTML 1.0 Transitional standard (a bit more rarely - 1.0 Srict).

If I was invited to vote, I'd have chosen the XHTML option ;-)

Cheers!

jsumners

optimiced: Do you have any real reason for that choice? Or do you just choose it because that is the trend? If you read my first post, and the articles linked within, you will learn that there are very few reasons to actually use XHTML. In fact, there are many reasons why you _shouldn't_ use XHTML over HTML.

I don't really view this as a matter of opinion. It is a technical matter.

optimiced

Well, I am a designer. Since tables started to go 'over the window' and the new, better ways of designing webpages came around (separation of content from presentation), I've been reading and doing a lot of web work myself, and embraced Web Standards as soon as possible (in fact, I have only a couple of sites designed with tables for layout, and also mind that at the time Netscape 4.7x wasn't dead yet:)

I noticed, that there are some good designers (I think most of them), which prefer XHTML 1.0 over HTML 4.01 -- see Dan Cederholm, for example, and many, many others. There are also other good designers, which prefer HTML 4.01 Strict (see Roger Johansson, for example, and others).

I prefer XHTML 1.0 Transitional. It's easy for me to code in it, and also, it's a bit newer standard compared to HTML 4.01. Before, I was used only to HTML 4 and to learn XHTML was a bit difficult; now that I mastered XHTML, it's a bit difficult for me to go back to HTML 4. Learning habits, you know

I don't think a web page will work better or worse, based on selected doctype only. Both HTML 4.01 and XHTML 1.0 are OK. So, in this case, one may say, it's a matter of personal preference and how widespread is one and the other standard. I believe that currently XHTML 1.0 is more widely used than HTML 4.01. Most of today's web software is XHTML 1.0 oriented, with regards to code it uses in its HTML templates. So I think, using XHTML 1.0 there's no harm done:)

That's my opinion...

As to HTML 5, (strange? why W3C makes first HTML 3.2, then 4.0, then XHTML 1.0 and then HTML 5.0?), I don't know too much details yet, and also, some time will have to pass after this is accepted as new standard and before browsers start supporting it... Till then, HTML 4 and XHTML 1 will be used in 99.99% of the cases:)

acrylian

As to HTML 5, (strange? why W3C makes first HTML 3.2, then 4.0, then XHTML 1.0 and then HTML 5.0?),
As far as I know that happened because they changed their mind, originally XHTML should have followed HTML 4.

trisweb

I still tend to agree that using XHTML is not necessarily a bad thing, even from a purely technical viewpoint. It's encouraging the use of modern browsers which can support XHTML, and forging a transition to a web where XHTML actually does work and is the 'norm' for technical reasons. And, once browsers support it, we can change to the correct valid form with xml header and CDATA blocks and all, without changing the entire form of the markup. For now, it's simply not a big deal to change and works "as-is," so it's not a priority. If we overhaul the template engine or something we'll bring it up again.

jsumners

optimiced: So you use XHTML because it is a trend. The syntactic difference between HTML 4.01 Strict and XHTML 1.0 is minimal. You only have to remember to "close" every element, even stand alone elements, and form your CDATA blocks correctly in XHTML. The technical differences, though, are giant. XHTML is _not_ HTML. It is an XML document that is very similar to HTML. Serving XHTML as HTML, while it generally works, is incorrect. Appendix C of the specification gives explicit instructions for agent developers to follow if they wish to process XHTML as HTML. Note the distinction "as HTML." XHTML != HTML. It's that simple.

I am please that you are learning to develop according to the web standards. You will be a better web developer for it. But please take the time to understand the standards you are using. Read the specifications (HTML 4.01 and XHTML 1.0). Read the articles I linked. And read this new one -- http://www.joelonsoftware.com/items/2008/03/17.html -- that has a slightly different take. Don't just blindly support one specification over another because some prominent designers do. If they are worth the weight their name carries, they have taken the time to understand these things and have made their choice for good reasons.

In regard to your question about HTML 5. As acrylian said, XHTML was meant to be the successor to HTML. But, because of the arguments in my original post (and a few others), the W3C is stepping back from that position. HTML 5 is meant to bring HTML up to modern technology while retaining the simplicity of HTML. See http://www.alistapart.com/articles/previewofhtml5 (they even provide a short advantage checklist for HTML and XHTML in the article).

trisweb: I disagree with the stance that XHTML encourages the use of modern browsers. If a web master were to server XHTML documents as XML today, his site would instantly become useless. As acrylian mentioned in the "block right click" thread, a majority of users don't understand, nor care about, the technical details. They just want their web browser to display the data correctly (Joel also goes into this in the article linked above). XHTML documents served as their legitimate type (XML) will not work in any version of IE, and the person using IE (of which there are legion) will call it broken and never revisit.

Like you said, if we overhaul the template engine this point becomes moot. So does your point about easily fixing CDATA in the future. That is why I have suggested that a conversion to HTML from XHTML be tied to an overhaul of the template engine.

optimiced

Well, let's say so: It's not only trends, for me.

If today 80% of people use XHTML 1.0, and if XHTML 1.0 and HTML 4.01 are very close, then why should we go away from XHTML 1.0 now? Why it's evil?

1. If I make my document HTML 4.01 Strict, will it load faster than XHTML 1.0? No.
2. Will it display better? No.
3. Will it affect performance of my browser? No.
4. Will it make display my page a tiny bit better in any browser of today? No.

Any browser of today that understands doctypes, can render perfectly both HTML 4 and XHTML 1.

So, when HTML 5.0 becomes a standard, when browser developers start making their browsers compliant not only with HTML 3.2, 4.0 and XHTML 1.0, but also with this new standard, then we can start making changes in our ways of developing for Web accordingly. Till this moment comes, I think we're perfectly safe using HTML 4 and XHTML 1, according to our own choice, and (in some cases, like when developing web software used by others, not only for our personal use), according to what will be most useful for most people. And in the case of "XHTML vs HTML", I think XHTML will be preferred by most. This doesn't meant it's better, but simply preferred.

Finally, I think the discussion now drifts away to shores where a Flame War might start between Web purists, a war over the question, which standard is better and most convenient and righteous, and I don't think we want this

I just wanted to show my own point of view in this matter :-)

// Sidenote: Ah, and yes, I know developers of today *do not* serve correctly the XHTML, precisely because IE cannot understand the document then. But if you ignore this fact, then you can see that even if incorrectly served, the XHTML documents display fine on the Web, just like their HTML brothers, so why should we be worried by this fact? And maybe one day IE will be fixed:)

jsumners

"If today 80% of people use XHTML 1.0, and if XHTML 1.0 and HTML 4.01 are very close, then why should we go away from XHTML 1.0 now? Why it's evil?"

Read what I have written and linked! I have answered that question multiple times.

There are a couple of reasons why those 80% of people use XHTML 1.0. 1) They don't know any better. Someone told them "Use XHTML 1.0" so they did. They don't know the difference, and they probably aren't writing valid XHTML. 2) They know better, but use XHTML because they are lazy. They think XML's strictness will force them to write valid markup, and we know this isn't true. They don't care that they don't have any real reason to use XML over HTML.

I haven't said, at any point in this discussion, no one should ever use XHTML. There are perfectly valid reasons to use it, despite the fact that it has to be served incorrectly. E.G. If you want to use MathML. MathML is a better fit with XHTML than with HTML. MathML is an XML namespace just like XHTML.

"Finally, I think the discussion now drifts away to shores where a Flame War might start between Web purists, a war over the question, which standard is better and most convenient and righteous, and I don't think we want this "

That is not what this discussion is. You seem to be trying to turn it that way by ignoring the evidence and the underlying question, but this discussion is about choosing the proper technology for the job. There isn't one single bit of ZP, as it stands now, that needs XML. The only thing that could possibly justify its use are RSS feeds. But those are not embedded in the XHTML, so they are not much of a factor.

Finally, I have not tried to convince anyone here to use one technology over another in their projects. If you really want to use XHTML, fine, that is your choice. In fact, my suggestion for "fixing" ZP would allow you to use whatever technology you want with ZP. Be it HTML 3.2, 4.0, 5.0, or XHTML. It isn't going to happen any time soon. No one who works on ZP has the time to make the change. But that doesn't mean it can't be discussed.