sneakyimp;10992055 wrote:
Note in particular the simplicity of the doctype declaration.
2 - HTML4 or HTML5?
It seems pretty clear to me that we should try to use the latest, but I worry about old browsers and wonder how they might respond to the extremely simple doctype declaration (what with no DTD and all).
Simple is good! But do note that even XHTML 5 needs a doctype declaration. The document should look like this.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
Do note that in XHTML even the doctype declaration is case sensitive. It has to be uppercase DOCTYPE and lowercase html.
I also find it interesting that some browsers (at least Safari) allready treats documents as HTML5 even when you are using an HTML 4.01 or XHTML 1.0 doctype. I discovered this when a site which for several years had set a required attribute on form elements where the attribute value was a string containing feedback to the user if they didn't fill out such an element. Suddenly, due to the introduction of the required attribute in HTML5, Safari had issues with these elements if they weren't visible ("collapsed" parts of the form) and not filled out. There would be no feedback to the user and the form would not submit. The HTML 5 check against the required attribute kicks in before the form onsubmit event handler, so the old javascript code was no longer executed.
So with some browsers treating all documents as HTML 5 while IE8 doesn't seem to have problems with the new doctypes for (X)HTML, I see no reason not to use them.
To avoid the risk of IE8, and most likely 9 as well, going into crap mode, you should set
header('X-UA-Compatible: IE=edge');
which also removes the button called "Compatibility mode" next to the address bar.
sneakyimp;10992055 wrote:
1 - XHTML or HTML?
Does anyone have any anecodotes about why they chose XHTML vs. HTML or vice versa?
I originally chose XHTML because I wanted explicit end tags to be needed as opposed to this valid HTML code.
<p>Paragraph
<p>New paragraph
sneakyimp;10992055 wrote:
3 - What media type?
text/html
XHTML documents need either application/xhtml+xml or application/xml media type.
IE8 (9?) still doesn't understand application/xhtml+xml.
however, if you allow IE8's standard behaviour of "content type sniffing" (Microsoft speech for "we know what the content type should be for stuff you deliver - you don't". They claim this is for security reasons), this isn't a problem since both HTML and XHTML will be treated as having a mime type of text/html no matter what you tell the browser. You can check this behaviour like this
<?php
# Uncomment the first header to stop IE's foolishness
# header('x-content-type-options: nosniff');
header('X-UA-Compatible: IE=edge');
header('content-type: text/plain; charset=utf-8');
?><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Example document</title>
</head>
<body>
<p>Example paragraph</p>
<p>Another paragraph</p>
</body>
</html>
Any sane browser recognizes that you are sending plain text, and doesn't treat the text in any particular fashion. That the text being sent happens to look like an html document doesn't matter, because it's not - it's a plain text document containing html code. IE8 will however serve the document as text/html, just like it would for application/xhtml+xml that it doesn't even understand.
So the choice is to either use the correct mime type and rely on IE's crap to make things work, or to tell IE to shut up and do what you tell it to do and instead go with text/html even for XHTML documents.
sneakyimp;10992055 wrote:
And how do we deliver these media types? Can we rely on Apache or should we always take care to use the [man]header[/man function?
I prefer always setting content-type header myself so that it's explicitly clear what mime type and character set are being used.
sneakyimp;10992055 wrote:
Does anyone have trouble specifying the encoding with their text editors these days?
Not personally. There are people on these boards from time to time that do have issues with some Windows editor (notepad is one) which insists on inserting BOM. I believe it shouldn't be used at all since it actually has nothing to do with byte ordering. There should however be plenty of no-bom-utf-8-able editors no matter what platform you're using.
sneakyimp;10992055 wrote:
When serving these documents, how do we specify the charset?
using [man]header[/man] and declaring content-type?
Use a Byte-Order-Mark (BOM) in the file itself?
Using a meta element
Like I said before, I personally prefer to always specify content-type header including character encoding information.
* Using BOM with PHP files will cause problems most of the time. The HTML spec explicitly states that BOM is ok and sufficient to provide information about the character encoding used, but I would still not recommend it. If you ever want to read the file contents using for example PHP and possibly merging that data together with something else, you no longer have a leading BOM, you have 3 bytes of crap in the middle of your data.
If you are serving stuff with PHP, the file can't contain a BOM if you want to set headers. You could however start your output with
# headers and stuff here
# Send Unicode BOM before any other output, including doctype
echo '';
* I would recommend to not only send content-type headers, but also use the meta http-equiv content-type element (still allowed in HTML5) since PHP DOM needs it to treat HTML documents as being in utf-8. At least it did need it when I used PHP DOM the first time and I've never rechecked this. It's also entirely possible that the meta element introduced in HTML 5 works in PHP DOM, and if it does I'd go with that instead of the http-equiv since it's simpler.
sneakyimp;10992055 wrote:
5 - Template Engines: How do we separate PHP logic from HTML and styling?
… often require extra steps to package up your data in an array …
… one often has to learn some bizarre new looping syntax …
… There are also performance considerations …
Can anyone recommend a good approach to templating? Ideally one that is somewhat well-known to CSS jockeys and that plays nice with Javascript.
The only one I've ever used is Smarty, and I like it.
You don't (usually) need to give your variables special treatment. Accessing instance variables and methods works fine.
{$foo->pubVariable}
{$foo->pubMethod()}
I can't think of an example right now, but I have had to use an intermediate variable once or twice, but perhaps that was me not doing things the right way or a now outdated smarty version.
This means that you don't have to create arrays of db result set resources either. But you could also create a custom "block" function which executes a db query, assigns the selected columns to variables of the same name, inserts pagination if needed and shows "Nothing found" if no rows were returned. If you have such a block function called "list" this one would execute the query once and then iterarte until the result set resource has been consumed.
{list query=$membersOlderThanfourty}
Name: {$member.name} <br/>
Member since: {$member.since}
{/list}
where $member would have been assigned in the block function list. On a side note, you may also create normal functions (no closing {/funcname}) used in a similar way if you for example would want to create a little user profile box containing an image, name and online status. Reusing the above example
{list query=$membersOlderThanfourty}
{memberbox id=$id}
{/list}
Looping is no problem
<!-- foreach loop -->
{foreach $arrayvar as $itemvar}
...
{/foreach}
<!-- for loop -->
{section name=i loop=$arr}
$arr[i].elem
{/section}
You can turn caching on and off and even set different cache lifetime for each template. Also, the template is initially turned into a "pre compiled" version, meaning that it's turned into PHP code. If caching is turned on, a cached file will also be generated for straight output until it expires. You may also easily set things up so that a database is used instead of files for your smarty code. Thus $smarty->display('resourcename such as "file.tpl"') and $smarty->fetch('resourcename') may access either files or a database.
Well known? No idea. But smarty does work with anything, except that a little care needs to be taken for CSS / javascript. The default left and right delimiters are { and }, which means that
function jsfunc()
{
var d = document;
}
wouldn't work. But, you can set ldelim and rdelim yourself, for example: $smarty->ldelim = '<';
$smarty->rdelim = '>';
but, whatever delimiters you choose, you are likely to end up having trouble with them in the end.
You may instead use one of these approaches
function jsfunc()
{ldelim}
var d = document;
{rdelim}
/* or turn off smarty parsing entirely */
{literal}
function jsfunc()
{
var d = document;
}
{/literal}
