How to Share Code with Users
Jens Meiert, September 8, 2008 / October 2, 2008.
This entry is filed under Web Development.
Anyone sharing HTML/CSS code with users might want to follow a simple advice: Make sure that the code is at least valid and that it ideally, formally works in both HTML and XHTML.
Focusing on at least valid code – it’s the second step to go for truly semantically appropriate and “compact” code I fear – should be obvious. “Invalidating” other people’s sites doesn’t sound that nice anyway. Recommending that code to be insertable without modification in both HTML and supposed XHTML might not necessarily be that evident: I’m pointing that out because it’s often not only possible to offer the same code for both flavors, it’s in fact vital because such code significantly improves usability and, ultimately, user experience as well as it makes it easier to choose. One option instead of, albeit rarely spotted, two.
So similar to the plea to improve B2B ad code, let’s have a quick look at a fictive code example to actually demonstrate how that can work:
<p>My awesome <a href="http://example.ms/?foo=bar&baz=scribble">app</a> …<br> Nothing can beat it once it’s on your site.
Technically valid HTML, except for the classic ampersand issue.
<p>My awesome <a href="http://example.ms/?foo=bar&baz=scribble”>app</a> …<br> Nothing can beat it once it’s on your site.
… now fixed. Making this code snippet formally fine to be included in XHTML is simple, however, the br element seems to deserve different treatment in HTML and XHTML, and we’re going for both. The idea is to do what (web) development sometimes asks us to do, to look for alternatives. And, CSS – our reliable partner for styling questions – to the rescue, replacing the br element by a p element allows us to deliver code nobody can complain about. Unless you’re an example nit-picker, that is:
<p>My awesome <a href="http://example.ms/?foo=bar&baz=scribble">app</a> …</p> <p>Nothing can beat it once it’s on your site.</p>
Lazy Jens just hopes that this made sense. Code shared with users is special, especially regarding “compatibility” (different environments, here: document types) and maintainability (it better be good before the first update already requires users to change the code or you to piggyback legacy code).
And yes, I know that this “how-to” can mean inspiration for a few larger companies as well. The “make sure the HTML is at least valid” part’s not to be forgotten.
Read More
Enjoy the most popular posts, probably including:
Comments
-
On September 8, 2008, 12:13 CEST, Jens Nedal said:
This certainly works great for templating and i have handled it like this during my career in those cases where we just did the templating and nothing else.
Both HTML and XHTML are equally used and simply have valid code in the first place helps this process alot. The & is one of those nifty little points most people will miss, though you should see it when you validate your pages.
Also providing valid code is simply a must, especially from your professional standpoint. There will always be some customer who actually knows a bit about how designing pages work and some of those who like to nitpick will especially know about ways of finding flaws. So providing templates that validate in either HTML or XHTML is your first step.
Beiing able to provide this for both cases is an absolute plus. Thanks again for worthwhile knowledge and input Jens.
-
On September 10, 2008, 18:32 CEST, Jens Meiert said:
Thank you, Jens – and let’s hope that discussing these issues has some effect, as taking more responsibility, and be it “just for code”, would really be a good thing.
-
On October 3, 2008, 22:22 CEST, Louis said:
Aren’t you changing the semantic of the code when you split the paragraph in the first snippet into two paragraph in the second snippet?
I mean, in XHTML, aren’t the following two example snippets semanticaly different?
<p>phrase 1<br />
phrase 2</p><p>phrase 1</p>
<p>phrase 2</p>
