C:\ Home » 2012 (Page 7)

What Is XHTML Namespace?

XML namespaces are used for providing uniquely named elements and attributes in an XML document. They are defined in a W3C recommendation. An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved.

Yupp, that didn't help me much.

A namespace name is a uniform resource identifier (URI). Typically, the URI chosen for the namespace of a given XML vocabulary describes a resource under the control of the author or organization defining the vocabulary, such as a URL for the author's Web server. However, the namespace specification does not require nor suggest that the namespace URI be used to retrieve information; it is simply treated by an XML parser as a string. For example, the document at itself does not contain any code. It simply describes the XHTML namespace to human readers.

F0r real? Is the explanation within reach?!

XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references.


We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a "markup vocabulary") that are defined for and used by multiple software modules. One motivation for this is modularity: if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it.

Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name.

These considerations require that document constructs should have names constructed so as to avoid clashes between names from different markup vocabularies. This specification describes a mechanism, XML namespaces, which accomplishes this by assigning expanded names to elements and attributes.

Yeah, uhuh...

In XML documents which conform to this specification, element and attribute names MUST match the production for QName and MUST satisfy the "Namespace Constraints". All other tokens in the document which are REQUIRED, for XML 1.0 well-formedness, to match the XML production for Name MUST match this specification's production for NCName.

Sounds... important. W3C and Wikipedia couldn't answer my wonder, so I kept searching...

I found a post by Elliotte Rusty Harold. Add an xmlns="" attribute to every html element he says. Why? I wonder.

XSLT and other XML-based tools can treat the same element differently, depending on its namespace. XML-based XHTML tools expect to find HTML elements in the XHTML namespace and will usually not function correctly if they are in no namespace instead.

Furthermore, many browser extensions such as XForms, SVG, and MathML operate correctly only when embedded inside a properly namespaced XHTML document.

And I'm still wondering! I probably need to know more than HTML & XHTML to understand what this is all about. SGML? XML? How deep do I need to dive? Or maybe, somewhere, there is someone who can explain in an understandable human language what the XHTML Namespace really is. If I find out I'll let you no.

Why Use <code> When There's <pre>?

The <pre> tag defines pre-formatted text. Text used within this tag has a fixed width, IOW it uses a mono-spaced font, usually courier.

It looks like this.

The <code> tag works similarly, though it's written specifically for code. It looks like this. Occasionally I post some code on the blog, and every time I wonder... which tag should I use to include it? I usually settle for code... since that's what I'm posting. Reading the basics anew I started wondering, why use code when there's pre? What's the difference? Why did W3C add an extra tag with the same properties and manner of display?

It turns out there is a difference! The <code> tag is meant to be used for inline code that can wrap and the <pre> tag for block code that must not wrap (see example above). Additionally, you could wrap the <pre> tag around a <code> tag to turn the inline code into a block (but never vice-versa). This might be extra useful if you've styled the code element through CSS or JS to display it in numbered rows, or a different color, or something fancy that makes it look like kind of like you're looking at the source code when you're seeing a page, but you don't want to make all code appear as a block. The <pre> tag can be used for many things other than code, too.

when I first included a line of code, I thought the <code> tag would take care of everything. That it would not only keep all tabs and spaces intact but also display all the tags in text form. Turns out this was not the case. When including code on a page, either the left or right bracket in a tag (or even better, both) must be replaced with &lt; or/and &gt; to remain in their regular text form.

Btw, if you want to show the code for the < and > brackets (&lt; and &gt;), you'll need to escape the & at the start of the code by using &amp;, like I did above. Just recently I wrote &amp;amp; so you could see the &amp;, but of course I had to add an &amp; so you could see both of them, which means I actually had three amps in a row. What you see is never really how it looks! Including code is complicated! :D

Firefox 2, Safari 2

Back in 2008, these two major browsers were stuck on their second edition. The latest versions right now are FireFox 17 and Safari 10. Time flies! But apart from the version numbers, has there really happened that much in the past 4 years?

Firefox 2 also introduced better support for feeds, inline spell-checking, support for SVG text (I'm curious about SVG btw, will post a blog about it later), resuming browser sessions, phishing protection and new windows opening in new tabs, by default! All of this is so common now it's hard to imagine what it was like earlier.

Safari 2 introduced integrated RSS, Atom and PDF viewing, as well as private browsing and parental controls. In a time before Chrome, those two latter features were way ahead of its time! Facebook overtook Myspace in 2008 though, so they were indeed needed features. Since then, only speed and functionality have been tweaked with each release, no remarkable new features.

It was a special year! It was also the year that Internet Explorer 6 came out, a popular browser at the time. It is also a browser which has lived much longer than it should, considering all the issues designers have had to face over the years while trying to optimize their sites to work properly on IE6. The other major browsers have never posed such major problems, and it took a while before IE finally caught up to the competition. Or has it? Maybe IE 10 will be just as much of an issue in another four years...

Citing Your Citations

I quote a lot on the blog, but for the most part I use the <blockquote> tag and not <q>. The latter is aimed at inline quotation; if I find a quote I want to post, it's not going to inline, it's going to be a point of focus deserving a block of its own. But moving to another matter, the one I was going to talk about in post, the <cite> tag. Who uses it? How do they use it? Why should you use it?

Apparently, there are quotations and there are citations. Quotations are verbal and citations are written. A quotation is something a person said, a citation is something they wrote. On the net, a citation is the title of something that person wrote, and the <cite> tag can be used to mark such a title within the text. The cite tag was formerly used in conjunction with a persons name, but now it's the publication that should be referenced; as the W3C so humbly put it...

A person’s name is not the title of a work — even if people call that person a piece of work...

It'll probably take a while before anyone starts using this tag on auto, though. Currently it's a more used attribute than it is a tag of its own.

Merry Christmas!

The Edible Tree

No I'm not awake yet, I'm auto posting this the 23rd. :)

The grand day of Christmas, the one where we open our presents and stuff, and are surged by an urge to dance around our newly home-brought pine but can't because the living room is too small, and eat porridge for breakfast, and open COOPs calender at 10 instead of 15 as has been the usual for the previous 23 days, and swap the traditional heavy metal and hiphop to more traditional tunes, this day that only appears once every year! I don't like to spend the majority of it as I usually do in winter - by the computer. So, I did things that I might need to do tomorrow in advance, like posting this, and finishing all my studies (yeah right) and other stuff. If your reading this right now (now being between 0-12 on the 24th of December 2012), maybe you should go spend some family time instead? ;) Or maybe you don't have the time, or family, in which case I provide my humblest apologies for upsetting your Christmas setting; I wish you a good one all the same!

Merry Christmas! Hanuka! Etc! Whatever you celebrate! Your birthday maybe? Someone else's birthday? Whatever the reason, may the day be prosperous and blissful and full of presents you really need and wish for, and good food and laughter and happy people! I leave you with a picture of an edible tree. Guess which anime? ;)

The Future Of HTML & XHTML

I stumbled upon some wisdom today.

HTML is based on SGML. SGML is an old standard, and is used to define markup languages for all sorts of purposes. XML is also based on SGML, but is completely seperate from HTML. HTML allows for a much wider variety of SGML features than XML does. XML's main features are a very simple syntax and draconian error handling, which makes it suitable for marking up error-intolerant documents and also makes it very easy to learn.

During the XML craze of late 20th and early 21st century, someone has the idea of making an XML-version of HTML; XHTML. The idea was that, since XML was already being used a lot in various applications (such as vector graphics (SVG) and mathematical markup (MathML)), this would make it possible to easily extend the HTML page to natively include such additional elements.

The only problem was browser vendors and page authors. Page authors were told that XHTML was the new black, and that everyone had to start using it, or they'd miss the cultural revolution of Web 2.0. Nobody really knew why they were using XHTML rather than HTML, except everyone else was doing it. As a result, everyone did it wrong (and still do). At the same time, the browser vendors couldn't exactly built their web browsers so that they were incapable of displaying XHTML pages, as long as their competitors didn't do it as well.

The XML declaration is not necessary, unless you use XHTML 1.1 (which you shouldn't). With HTML 5 supporting the general concepts that originally gave birth to XHTML, XHTML will die a slow and painful death over the next 20 years. Until then, HTML 4.01 is still the latest standard advisable to public websites.

Privacy   Copyright   Sitemap   Statistics   RSS Feed   Valid XHTML   Valid CSS   Standards

© 2019
Keeping the world since 2004.