Politics at the top. Useful criticism at the bottom...
Hannes Magnusson skrev:
Right. As I see HTML5 it is simply a "how to deal with errors"
appendix for browser vendors.
A point that I tried to correct. It is much, much more than that. It
includes new elements and attributes, it deprecates all presentational
markup still left in (X)HTML with the strict flavor (good bye "rows"
and "cols" on textarea - finally!), it provides API:s and DOM bindings, etc.
PHP's documentation should perhaps not move to HTML 5 (yet). But not for
that reason.
There is no such concept as "valid web page" implemented on the web
today. validator.w3.org doesn't send out correct headers and neither
search.yahoo.com or google.com validate.
a. Yes there is. E.g. Google makes a plethora of services besides its
main search page, where validation is part of the development process.
In fact, Ian Hickson, editor of the HTML 5 spec, works for Google!
b. Most invalidness comes from CMS-vendors doing a crappy job. Often
because they think front end dev is "beneath them". Many developers are
craving better CMS's in this regard and if PHP can lead the way it will
benefit the language greatly. All mailing lists and fora on web design
and front end dev are littered with questions like "where can I find an
CMS that produces good markup"!
c. One could also argue that there is no such thing as well written
PHP-code implemented on the web today... Since *most* of it is crappy!
The web is a tagsoup. We try to use as semantically correct markup as
we can, but there is no way in h3ll everyone can write strictly valid
pages. We shouldn't need doctors degree in markup to write web pages.
C'mon, it isn't that hard! There are plenty of things in PHP-land that
are much harder to learn.
And if someone has a specific markup related question for the manual, I
am willing to answer them. Just CC me since I am mostly lurking on this
list.
What PhD does is to convert extremely semantically correct XML to
(x)html(-ish) markup, injecting eRDF (and some microformats) semantics
where it can to further improve the semantics. There is no way we can
possibly make all pages "valid".
PEAR requires all code to follow certain conventions. So does almost
every other well established app. Why isn't that considered impossible
or unnecessary?
Besides, there are tools to help us. CodeSniffer and Tidy. JSLint and
validator.nu. Etc.
In fact, PhD is already quite well on the way to have really good HTML.
As long as the browsers understand
the markup and present it relatively alike then I am satisfied. I
really do not see the point in wasting hours (and performance) in
working around block elements inside inline elements, or nested
paragraph tags.
Valid and semantic code is not only about rendering. It is about ease of
maintenance, ease of finding and fixing errors, ease of enhancements.
And I seriously doubt that anyone can provide a case where correct
markup degrades performance - where the markup is the culprit. Right now
Google, Yahoo and others spend lots of time investigating web
performance. No expert on this belittles the importance of semantic and
valid code!
Browsers have implement this since the beginning.
With HTML5 the "invalid markup" will become consistently rendered in
the browsers and that is all we need; consistent rendering.
Isn't that the defense of a PHP developer who dislikes using patterns,
coding standards, etc? "It works - that is all I need."
Let's also remember that even though HTML specifies how browsers should
treat non conforming markup, no browser yet follows the HTML 5 parsing
rules. (Mozilla has started their work, hiring Henri Sivonen to lead it,
but they are far from finished.) PhD users will not benefit from this
particular part of HTML 5 for many years yet. In todays browsers invalid
HTML really do cause unpredictable results. (Valid code do cause that as
well, though, because of browser bugs... But to sligthly lesser degree.)
And what about accessibility? "Consistent rendering" for normally
sighted users on a PC or Mac is not the same as fully working for people
using assistive devices, small screens, etc.
I'm not saying that I'd veto patches to fix PhD rendering, but at the
cost of massive performance degradation or hours of work... really?
Should we really bother?
Once again: "Massive performance degradation"? Not true.
Lets rather spend some time on researching the various RDF
vocabularies that we can implement using RDFa or eRDF, or even
microformats, we would gain so much more on that.
And having POSH markup as a foundation will very much *help*
implementing microformats and RDF!
Separating design from content by removing all presentationally oriented
elements and attributes and switching to strict DTD (or perhaps HTML
5) is not anything that will prevent PhD from using additional goodies.
_________________
BTW, checking a few random pages in the manual, there are very few
validation errors - but incorrect translation from latin-1 to UTF-8
means that illegal characters exist and prevents easy validation -
courtesy of the user submitted notes. This in turns mean that not even
rendering will be what the user intended.
The main markup errors I found (taking a cursory glance) are:
(a) using the target attribute to open links (also in user notes) in a
new window, which requires the frameset DTD. This should really be
avoided. Most users find such behavior annoying.
(b) There is an align attribute on the "add a note" image starting the
user note section.
(c)
<input type="image"
src="http://static.php.net/www.php.net/images/small_submit.gif";
id="changeLangImage" alt="" />
Missing alt-text. Should be something like "change language" (i.e.
describing function, not looks.) This is *not* a decorative image.
The main problem is all the inline styles in the PHP-markup. Ironically,
they only exist in the proper manual. User submitted code is marked up
using classes! Sic!
(d) Notes are marked up as blockquotes. They are not quotes.
<div class="aside"> is forward looking markup, that can be changed to
just <aside> when browser supports HTML 5.
(e) Headings in the notes are marked up with the b-element, when they
really should be headings. This is "bed and breakfast" markup. <b> +
<br> where a heading is the right element fir the job.
Minor gripes:
(a) Anorectic anchors:
<a name="87685"></a>
<div class="note">
Should be shortened to:
<div id="87685" class="note">
Saving bytes...
(b) The strong element is used to produce bold text, even though no
emphasis is intended. When the heading is repeated above the user
contributed notes it should be marked up as a heading. Not using strong.
Users that contribute notes should not be put in bold using strong either.
In fact HTML 5 *recommends* using the <b> element for exactly such
usage: http://www.whatwg.org/specs/web-apps/current-work/#the-cite-element
(c) Concerns all of php.net
Using vertical bars to separate links in a menu was actually recommended
- in the 90's! Today such a list should be marked up *as a list* and
styled with CSS. And adding the aria role of menu will greatly help the
accessibility of the menu. http://www.w3.org/TR/wai-aria/#menu
(d) Redundant classes?
<p class="para"> Are there any plain <p>'s?
<em class="emphasis"> When is <em> not used to denote emphasis?
BTW, I changed the heading of this thread. Using XHTML or HTML is a non
issue. Using a strict DTD is way more important than using XHTML. HTML 4
strict is to be preferred over XHTML 1.0 transitional in every way.
And presentational markup, divitis, spanmania, "bed and breakfast"
markup, anorectic anchors, etc are all possible faults to commit also in
XHTML.
Finally:
If the PHP community can be taught to embrace good front end coding
there is a huge opportunity for it. Check this out:
http://www.wait-till-i.com/2008/12/19/working-in-the-now-video-of-my-talk-at-paris-web-released/
and http://www.slideshare.net/cheilmann/working-in-the-now-presentation
Especially slide 40f.
Lars Gunther
![http://static.php.net/www.php.net/images/small_submit.gif"](http://static.php.net/www.php.net/images/small_submit.gif"){kind=link}