Hi Fábio,
I did already point out the two checks that cause the problem, I just don't know
the best, or "right" way to fix it for mootools (e.g. I don't really have any
idea what "slick" is or does)... I don't use mootools myself, but Joomla! adds
it to my pages by default and I'm sure it will come in useful when I have more
time to look at it.
On 26/05/12 18:20, Fábio M. Costa wrote:
As a note, why are you doing this? Why don't you use HTML?
Because you can't use other tools from the broader XML stack to process HTML,
only XHTML. For most people that is not important, but I do a lot of work with
Semantic Web technologies, for which XSLT, GRDDL, RDFa, XPath and other
XML-based tools are invaluable for processing document markup to add, extract or
generate structured data.
HTML5 is a monolithic subset of these things, which is a strategy I personally
struggle to make sense of. But this whole subject tends to be highly
contentious, is frequently debated yet never resolved, because people simply
have different objectives and different ideals. HTML5 advocates consider their
approach more pragmatic. Obviously I don't agree, but this isn't the most
appropriate forum to revisit that whole debate, I'm only explaining my viewpoint
here because you asked.
While it is entirely possible to serve XHTML as 'text/html' it is more efficient
for the browser to parse XML and I prefer to have it do that, especially during
development, because I can see immediately as soon as something breaks the
markup (because all you get rendered in the browser is an XML parser error).
There are some other fringe benefits (e.g. it used to be the case that MathML
would only be rendered inline within XHTML, until HTML5 added support for the
<mathml> tag explicitly) and the modular nature of XHTML allows extensions like
MathML, SVG, RDFa and whatever else people may next decide to add to web pages
without needing to create a new specification for the "host" document language
(i.e. the "host" spec is XML itself and the modular separation occurs by using
standard XML namespaces).
To me that is cleaner and saner, makes perfect sense and is not remotely
difficult or inconvenient. HTML5 designers didn't agree, but each to their
own... I don't mind what other people want to do, but at the same time I don't
see any harm in asking them to support my preferred standards also if they can.
The XHTML benefits are mostly outweighed by the inconveniences of 90% of
developers not adhering to sufficiently strict XHTML standards (more so with
their javascript than in the markup these days) to be able to serve it up to
browsers as actual XHTML. It makes no difference to add an XHTML DOCTYPE etc. if
the HTTP Content-Type says 'text/html' because the browser will treat the
content like any other potential tag-soup. There really isn't much point to
that. It doesn't help either that IE doesn't (or didn't, it might be fixed now)
understand the XHTML MIME Type.
So to a large extent it is just stubbornness that I continue to try to encourage
strict XHTML usage. But wherever I encounter issues in open source code for
XHTML, I try to fix them (directly or indirectly) and I think that helps code
quality overall, and I pretend to myself that this also helps to keep the
idealist goal within reach that one day we can finally have HTML become "just
another XML vocabulary" instead of it's own language with it's own dedicated
parsers.
Hoping somebody will eventually fix this issue in mootools...
Cheers!
-Will