⚠️ Urgent! Active Attacks on MODX Revolution Sites Below Revolution 2.6.5
Subscribe: RSS
  • Never thought about it that way! LOL! Good one, Ryan!
      Jeff Whitfield

      "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
    • What, only four and a half years left?
      Better get busy then!
      • Wow - not only did they accurately predict when the setting sun of the winter solstice would align with the center of the galaxy.. they knew how the whole html standards drama would unfold!
        Hmm... is Tim Berners-Lee a direct descendant of Pacal Votan?
        On a serious note, this has been a great thread - thanks zendak, Bravado and smashingred for thoughtful and balanced arguments.
          Mike Schell
          Lead Developer, MODX Cloud
          Email: mike@modx.com
          GitHub: https://github.com/netProphET/
          Twitter: @mkschell
        • Thanks for your feedback and useful points, everybody! Sorry, I’ve been busy in the offline world the last couple of days..

          First off, I’ve solved my original problem using a plugin that does a bit of string replacement before templates get rendered (probably similar to what smashingred mentioned). That takes care not only of RTE’s but also any other 3rd party code. Basically it boils down to removing the slash on a few "empty"/self-closing tags (meta, img, br etc.), which is quick & easy and with no noticable performance hit. The rest consists of making sure I write good HTML in my templates, snippets and so on.

          Some comments to your replies:

          I’m not trying to say that it’s horribly evil to do "fake" XHTML (sent as text/html and with the other slur of compromises mentioned earlier), so of course it’s okay to do that if you prefer. All I’m saying is, be very clear about the fact that you are sending HTML to the browsers. The MIME type is what’s important, not your DOCTYPE. So if you’re not really using "real" XHTML because you need its features, why do it at all? You can have the same "web standards benefits" using strict, valid HTML4. But again, I’m not militant about this, I agree that you need to be pragmatic sometimes and flow with project requirements beyond your control and so on. Besides, this whole discussion comes up every so often and always brings a "uh oh, here we go again" sigh to many people. And the last thing I wanna do is annoy people with endless nitpicking wink I’m just asking that people at least understand the issues. I know it’s tedious to do the research and there are more thrilling things to do than compare fine points of dry specs, but hey that’s part of the job as a pro.

          Bravado, I appreciate your line of thinking, i.e. that XHTML seems to encourage more rigid coding practices, which is a good thing. A while ago I was at exactly that spot, asking myself the things you did. But consider this: "Fake" XHTML is still just plain HTML for UAs. Actually, it’s invalid HTML, sort of ironic actually. Strict HTML4 itself is very much non-forgiving when it comes to validation. So it’s not HTML that’s "loose" or forgiving but the browsers’ handling, which is a different matter. Just remember that browsers will be just as forgiving if you write sloppy fake XHTML. Write sloppy real XHTML and your users are screwed.

          Your code sample is valid. Closing p tags are optional indeed for HTML4. Many people including me prefer to close them anyway, for optical orientation. What I do is basically stick to all the best practices that are required for XHTML in HTML4. I close all tags, even when optional, I don’t use the short form of boolean attributes (e.g. <option selected> vs. <option selected="selected">) and a few other things. That way, I have a consistent coding style which is one of the concerns you touched upon.

          Script libraries: It would be unwise if they didn’t work correctly with proper HTML4. I’ve only really used YUI (look at what DOCTYPE they use in all their examples) and jQuery so far and no problems have come up at all. Actually, if I’m not mistaken, innerHTML is not supported by real XHTML, and a lot of JS trickery seems to be based on innerHTML. Real XHTML requires namespace-aware DOM methods like createElementNS. Do current libraries even handle that? Not sure. Do I want to write two versions of all my scripts? Nope.

          Who knows what the future will hold (and how soon it will be here), (X)HTML5 looks promising, although there’s still work to be done and a controversial thing or two in there at this stage. Personally though, I think I’d rather bet on that than XHTML 2.0 Especially making consistent error handling for browsers part of the (X)HTML5 spec is a brilliant idea. But let’s wait and see. Nice Maya astrology reference, btw. Hey, perhaps this issue will even be the catalyst for the end of the current Kali Yuga shocked

          Just saw today that James Bennett coincidentally wrote about this stuff in a much clearer way than I’ve managed here, a good read for anyone still confused.
          Read in this order:

          Finally, to quote from the excellent Sitepoint FAQ that Bravado linked to (emphasis mine):
          Should I use XHTML or HTML?

          That depends on who you ask. There are a number of technical issues with this question, which preclude a simple and short answer. In reality, the latest W3C recommendation with widespread support is HTML 4.01. Unless you actually need any of the features that XHTML offers over HTML, there is no technical reason to use XHTML.

          In order to actually benefit from using XHTML, you really need to understand the fundamental differences between XHTML and HTML. Such a site will only be available to a small minority of the surfing population, however.

          Some web designers and developers prefer XHTML’s syntax rules over HTML’s. By following certain guidelines, you can use this syntax without technically using XHTML at all (see below). There are a number of potential pitfalls with this approach, but it is a possible way forward for those who absolutely want to type
          instead of

          For ’future-proofing’ your documents, using a Strict doctype is more important than whether you use XHTML or HTML.
          • Jay, sorry - looks like I ignored this issue in my last post.
            Quote from: smashingred at Jun 27, 2008, 02:55 AM

            One more point from the post you linked to, and this was one I got thinking about recently and that is the i element as a meaningful device. In writing there are all sorts of style guides that point to the use of italics to express differentiation over emphasis such as Sailing Vessels, long fiction, and other such standards. This is not emphasis as I’m not saying its important but that it is a specific thing. I’ve a client that I’ve been working with in the tallships industry and vessels standardly are expressed as italics or all caps. Caps is visually annoying and so I marked them up (originally) with em elements but after reading a number of articles over the last year, I opted to migrate to "I’ because it was more semantic than em.
            This is something I admit I’ve never really thought about critically until recently, when I was forced to by content requirements similar to what you describe. Come to think of it, it’s a common problem: How do you mark up things like unique names (of products, brands, ships/vehicles, buildings, software?, etc.) semantically? Do we need something like <uniquename> or <propername>? Often, in print, typographic conventions or style guides will let these be set in italics; but also small caps, boldface or any other distinguishing feature may be used to indicate the significance. Sure, CSS gives you stylistic freedom. But the markup should say something about it, too. I’ve used <em> and <strong> as "automatic" substitutes for <i> and <b> in the past, which I’m convinced now is not really all that clever and "right".

            It’s one of those little tough ones. There’s a very interesting blog post by Mike Cherim asking the same questions and providing some good examples of possible solutions. Here’s one of his subjective conclusions which I find sensible:
            If I’m writing a word or group of words and I want to convey to the reader that I want to emphasize said text and I want them to say it with vocal inflection, I use the emphasis element. But if I want to italicize text to convey thought or language changes — what I consider legitimate usages — I use the “i” element.

            Btw, I suspect this thread is going off-topic, especially since the brunt of it is now dealing with the XHTML vs HTML issue. Perhaps the topic should be split, not sure what the policy is here.
            • Btw, I suspect this thread is going off-topic, especially since the brunt of it is now dealing with the XHTML vs HTML issue. Perhaps the topic should be split, not sure what the policy is here.
              We’re pretty flexible here; and if the moderator thinks it should be split, he’ll split it and leave a message with a link to the fork.
                Studying MODX in the desert - http://sottwell.com
                Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
                Join the Slack Community - http://modx.org
              • Yeah, this is a good discussion. So if anyone wishes to continue it, feel free to create a new topic and add a link to this thread for reference. Definitely some good food for thought.

                Gonna end my thoughts on this by just reminding everyone that strict XHTML code with a text/html MIME type is still just HTML. There’s nothing special about it other than the strict syntax and validation. The takeaways I got out of this discussion is that which one you use is really all about your personal preference. As long as you’re going by what the specification says and you follow good coding practices, I don’t think either approach is wrong per se. I personally will be sticking with XHTML simply because I do appreciate the level of strict validation that the syntax brings. Virtually everything out there spits out valid XHTML code and thus to try and follow a strict HTML 4.01 doctype would mean doing away or creating a lot of hacks which I prefer not to do...but that’s just me. smiley

                Oh, and Zendak, regarding this:

                Quote from: zendak at Jul 02, 2008, 12:13 AM

                I’ve used <em> and <strong> as "automatic" substitutes for <i> and <b> in the past, which I’m convinced now is not really all that clever and "right".

                Problem is that nowhere in the HTML (http://www.w3.org/TR/html4/) spec does it mention that <i> and <b> are valid. <em> and <strong> replace these and are definitely the "right" way to do it. Reason is that the terms italic and bold refer to how text looks, not what it means. As such the W3C took <i> and <b> out of the spec. Hope that helps. smiley

                  Jeff Whitfield

                  "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
                • Though italics is semantically correct for things like book titles and other items mentioned in this thread, at least according to the AP style guide I think.
                    Ryan Thrash, MODX Co-Founder
                    Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                  • I’ve created a new topic: The semantics of <i> and <b> vs. <em> and <strong>
                    @Bravado: see my reply there.