Archive for the ‘Development’ Category

« Older Entries
Newer Entries »

Pareto analysis of CSS

Friday, April 3rd, 2009

Highlighted below are the most widely used CSS declarations.

These are used mostly because most of them are supported in all browsers, they are quickest and shortest to write and make most sense in terms of design of usable and accessible interfaces.

Once again, Pareto’s analysis exemplifies itself in a similar way to how it exemplified itself with HMTL (see Pareto analysis of HTML) which implies that CSS implementation is possibly more extensive than it needs to be for most web site types.

  1. :active
  2. :after
  3. :before
  4. :first-child
  5. :first-letter
  6. :first-line
  7. :focus
  8. :hover
  9. :lang
  10. :link
  11. :visited
  12. background
  13. background-attachment
  14. background-color
  15. background-image
  16. background-position
  17. background-repeat
  18. background-repeat
  19. border
  20. border-bottom
  21. border-bottom-color
  22. border-bottom-style
  23. border-bottom-width
  24. border-collapse
  25. border-color
  26. border-left
  27. border-left-color
  28. border-left-style
  29. border-left-width
  30. border-right
  31. border-right-color
  32. border-right-style
  33. border-right-width
  34. border-spacing
  35. border-style
  36. border-top
  37. border-top-color
  38. border-top-style
  39. border-top-width
  40. border-width
  41. bottom
  42. caption-side
  43. clip
  44. color
  45. counter-increment
  46. counter-reset
  47. cursor
  48. direction
  49. display
  50. empty-cells
  51. float
  52. font
  53. font-family
  54. font-size
  55. font-size-adjust
  56. font-stretch
  57. font-style
  58. font-variant
  59. font-weight
  60. left
  61. letter-spacing
  62. line-height
  63. list-style
  64. list-style-image
  65. list-style-position
  66. list-style-type
  67. margin
  68. margin-bottom
  69. margin-left
  70. margin-right
  71. margin-top
  72. max-height
  73. max-width
  74. min-height
  75. min-width
  76. outline
  77. outline-color
  78. outline-style
  79. outline-width
  80. overflow
  81. padding
  82. padding-bottom
  83. padding-left
  84. padding-right
  85. padding-top
  86. position
  87. right
  88. table-layout
  89. text-align
  90. text-decoration
  91. text-indent
  92. text-transform
  93. top
  94. visibility
  95. white-space
  96. word-spacing
  97. z-index

The use of above highlighted declarations is most common based on the projects I have worked on so far (small and large) and various analysis I have done on other web sites in the wild.

It does not mean that you are likely to use all of these declarations on all web sites.

It is also the case that some declarations are used for, essentially, wrong purposes. A great example is the use of line-height in order to position elements vertically, which, over time, can end up being counter-productive approach on larger web sites.

Nevertheless, line-height is a worth while declaration to utilise, for example, in order to make text easier to read on the screen as it is generally agreed that some extra spacing between the lines of text makes it easier to read off the screen.

Posted in Development, Intermediate | 1 Comment »

Semantic uses of <span> HTML tag

Tuesday, March 31st, 2009

W3C defines <span> tag in the same way as <div> tag. I would argue however that <span> has no semantic meaning associated with it, unlike <div>, which denotes some form of a division on a web page.

What is it for?

<span>s are great for adding ‘hooks’ into your HTML documents and lend themselves well to creating bigger aspects of semantic web (such as micro formats).

Unlike <div>, which is a block level element, a <span> is an in-line element, so it is really easy to use it inside the document ‘flow’ without affecting the layout and design.

<span>s are most often found within a bigger ‘soup’ of other HTML tags (see examples for better description).

Appropriate use

<span>s should be used for providing additional meaning to snippets of content which are below the description threshold of other (more semantic) tags.

Furthermore, <span>s provide us with an ability to further describe the content wrapped within otherwise semantic tag.

Example (good use of <span>):

<p class="message">
<span id="hcard-jason-grant" class="vcard">Jason</span> says: <span> is a great way to integrate microformats into bigger semantic document.
</p>

Inappropriate use

I have seen some developers use <span> tags in order to denote a component on a page. These are situations where <div> tag is much better suited for and should be used instead of <span>.

Example (bad use of <span>):

<span class="component">
<p><strong>Jason says:</strong> This is my message.</p>
<p class="reply"><strong>Grant says:</strong>This is a reply to a message.</p>
</span>

The above example is wrong for a number of reasons including:

  1. It does not validate because <p> (a block level element) is inside a <span> (inline element)
  2. Having more than just some straight snippet of content inside any given <span> block usually implies wrong coding of HTML. <span>s should therefore not contain any other tags within themselves, including nesting of <span>s.

Out of any element in HTML specification <span>s are the most semantically neutral.

Many developers claim that <span> and <div> are equivalent, with the only difference that <span> is inline, while <div> is a block-level element.

This, in my experience, is not true, since <div> contains semantic meaning and has been used for a long time now to add much semantic value to interfaces.

Although <span>s on their own are semantically neutral, they can be given much more semantic meaning by associating classes and ids with them.

This is regularly done when coding up micro-formats and works very well, as associating class names with a given <span> the layout of the given content can stay the same, while machines can pick up the exact meaning of the data within the tag perfectly.

Posted in Development, Intermediate | No Comments »

Emerging semantic web structure

Friday, June 27th, 2008

Components and/or widgets (in my view) already play and will play a major role in making up semantic web.

Components can be viewed as building blocks of future web ‘pages’ and are most likely (and already are to a great extend) reusable on any web page – with applications like iGoogle users are able to ‘build’ their own web pages by adding widgets to the page through various interactions including dragging and dropping.

Each component can encapsulate all its attributes (including meaning, structure, data, presentation and behaviour) and can exist on its own by being explicitly linked to various server resources such as pictures and style sheets.

Semantic component structure

Here is an overview of how I am looking at things at the moment and how things may (and already do to a great extent) work within semantic web environment.

Semantic Data Component Structure

Meaning

Outlines what the component means and is placed on the top of the stack because meaning is the most important aspect of semantic web.

Future pages are most likely to be ‘built’ out of components which may reside in any place on the web (i.e. ubiqutous web), hence if the two components on a single page have the same meaning confusion is most likely to arise.

Communicating the meaning of the data we are working with is today’s ultimate goal of good interface developers and generally software engineers.

Structure

HTML is the main (at least the most widely adopted and supported) language with which we can define the structure of a given web page.

There are obviously various ‘flavours’ of HTML we can opt for, but whichever version of HTML we choose to work with, it ought to validate against W3C specifications.

Furthermore, HTML strucuture can (and should) include (wherever possible) microformats.

They are machine readable aspects of semantic web and have already become part of the standards to a great extent and will be adopted more and more over time.

XHTML2 recommendation proposes the use of <section> tag to denote all sections on page.

This nicely leads into future structure of the web within which we could have standalone sections for various mash-up style web sites being developed by developers and integrated into the end system by users.

Data

Data layer is a slightly weird aspect of semantic web as it often contains meaning within it, but due to the fact that most data is not ‘formally’ structured that meaning is mostly lost, hence we need to use layers above to denote structure and meaning of data.

RSS is a good example of (fairly well) structured data which can carry within itself plenty of meaning (RSS used for news for example can be a very structured and semantic way of sharing data).

However, due to the fairly flexible structure of RSS specification, various developers have bastardised it and used it for sharing ‘everything’ through RSS, which, to a great extent, misses the semantic aspects of sharing data through XML feeds.

Plenty of data within web pages these days is also fairly loosely structured. Think about an average paragraph content within a <p> tag in an HTML page.

Presentation

CSS is the main technology we use these days in order to style pages.

They are a very simple technology, which offers massive scope for being misused to a great extent, and that misuse is to a large extent associated with many developers not understanding the nature of semantic web.

Good stylesheet structure and reusability is incredibly important for creating good quality and nice looking semantic interfaces today.

Behaviour

JavaScript is the final part of the current semantic technology layer cake.

It is interesting in its nature in so far that it can ‘dig’ into any of the so far described layers and is therefore subject to all those rules and some more, in order to make it work with less capable browsers.

In order to make the most of JavaScript and enhance the meaning of semantic components which are developed, JavaScript ought to be used in such a way as to add dynamic, behaviour based meaning to those components which help users better understand the purpose of the component and make its functionality more useful.

All of the above put together may make compound semantic web pieces of ‘data’ (semantic objects) which can be used and reused within any context and viewed through any type of browser.

Tags: , , , ,
Posted in Advanced, Architecture, Development, Intermediate, Visionary | 1 Comment »

Semantic uses of <div> HTML tag

Friday, June 6th, 2008

What is it for?

W3C specification is fairly clear about what the purpose of <div> tag is.

The full quote from W3C HTML specification is:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

Some on-line references say that <div> tag is ‘semantically neutral‘, but I would strongly disagree with this statement. <div> is essentially there to be used for denoting sections of HTML documents.

<div> tag stands for ‘division’ on page, hence it has a semantic meaning to it which can be infered simply from its name.

Appropriate use

<div>, coupled with and id or a class attributes, is semantically very strong statement which gives a meaningful top level structure to any HTML document.

Structure and top level semantics of HTML pages are very important parts of creating web sites of any size these days.

This aspect of web pages not only helps organise the application for end users, but also helps developers organise the application from the developer perspective, aiding overall usability of software (it is commonly forgotten that usability does not only apply to application interfaces, but also to the back end, as well as general day-to-day life).

We need to think about usability all the time, as we are developing products which need to be maintained and upgraded (scaled) in future in the most meaningful (i.e. semantic) way all-round and not just from the interface point of view.

Web developers who know what they are doing, understand that <div> tag is a very powerful tool in web development and create ‘objects’ on screen which are completely encapsulated within their own <div> tags with a relevant id which uniquely identifies that ‘object’ within any page.

Inappropriate use

How ‘granular’ should we go with <div> tag and what is the smallest amount of code we could surround with a <div>?

I tend to implement standards as strictly as possible, since I have found (over years) that approach to be the wisest approach (least error prone and most scalable).

‘Sections’ or ‘components’ on a page should contain at least 3 tags in order to be considered candidates for being surrounded by <div> tag. (I am sure someone will be able to come up with examples of where this does not stand).

It is important to avoid divitis in order to keep interfaces lean, fast performing and avoid code bloat (and therefore decrease maintainability of the application).

There are many examples within which a <span> will work as well as <div>, but semantically will not be as ‘strong’ as <div> and the code will still work, validate and make more sense.

There are also frequent circumstances within which other elements can be treated as a <div> and therefore use of <div> avoided, while achieving the same results.

Great examples of this situation are usually presented wherever ordered or unordered lists are used, in which cases <li> can (in most circumstances) act as a <div>.

A look into future

An HTML construct such as

<div id="news" class="component">Component content goes here<div>

means a lot and creates a very good structure on a modern web page.

Future automated semantic tools could potentially understand these conventions and be able to ‘pick up’ complete components from pages and create mash-ups which can work with content directly pulled in from any web site.

Treating user interface as an API and standardising HTML mark-up (in a similar way in which Microformats community does it) can enable any portion of any interface to become reusable anywhere.

Name spacing CSS files according to the structure of the <div> component based mark-up also leads to better CSS development, leading towards faster performing and much more scalable and easily re-skinable interfaces and generally smaller and leaner implementations.

Example

Good example of using <div> tag and utilising its full semantic power.

Tags: ,
Posted in Advanced, Development, Intermediate | 14 Comments »

Pareto analysis of HTML

Wednesday, June 4th, 2008

HTML stands for Hyper Text Markup Language. It is a language and it is intended mainly for text. Its initial purpose was to provide meaning to text documents which reside on the World Wide Web.

This initial intention of HTML got somewhat lost in the last 10 years of web development and large majority of web developers are only now waking up to this fact.

I would like to provide Pareto Analysis of HTML as it is used on semantic web development projects on day-to-day basis. Without fully understanding these tags, you are most likely not to be able to create a proper, semantic web site today.

There are around 100 HTML elements which have been made part of the W3C specification. However, only a portion of those tend to be used by developers on day-to-day basis.

Highlighted in the list are those elements which I deem to contain some amount of semantic ambiguity. In other words, developers tends to misunderstand the meaning behind these tags, which tends to lead to their lesser or greater misuse.

I will explain separately the reasons why I think these tags are misused and how they ought to be used.

  1. <div>
  2. <span>
  3. <p>
  4. <a>
  5. <table>
  6. <tr>
  7. <thead>
  8. <tbody>
  9. <td>
  10. <th>
  11. <caption>
  12. <img>
  13. <form>
  14. <input>
  15. <label>
  16. <fieldset>
  17. <textarea>
  18. <select>
  19. <style>
  20. <option>
  21. <legend>
  22. <html>
  23. <head>
  24. <title>
  25. <link>
  26. <meta>
  27. <script>
  28. <body>
  29. <em>
  30. <strong>
  31. <abbr>
  32. <address>
  33. <h1>
  34. <h2>
  35. <h3>
  36. <ul>
  37. <ol>
  38. <li>
  39. <dl>
  40. <dd>
  41. <dt>
  42. <object>
  43. <embed>

With the above list of HTML elements you should be able to semantically mark up pretty much 90% of any small or large web site today.

It is interesting to observe that less than half of the overall HTML specification is used on most web sites today.

This fact suggests that almost half of HTML tag set is obsolete as well as that HTML specification is arguably sufficient for the purposes it was developed for.

Some web developers may disagree with this statement, feeling that HTML is missing elements which could be introduced into HTML5/XHTML2 to make some common tasks easier and faster to complete.

However, in conversations with developers, I have rarely met one who was able to suggest any new tag, letalone one that was meaningful and did not only cover requirements of an average blog site.

Tags: ,
Posted in Advanced, Development | 7 Comments »

Overview of code editors

Monday, June 2nd, 2008

All said, here is another piece of observation. There is no such thing as a ‘perfect code editor’. They all tend to have their own advantages and also lack certain functionality which would be useful to have. At the end of the day, one needs to settle on a code editor and use the tool to the best of their ability in order to write good quality code consistently.

Free HTML editors

NetBeans IDE

NetBeans IDE took me by surprise as it is a very good IDE to use over and over again.

It’s light weight and work fast, offering very useful functionality of searching with files across the entire project, something that the notorious Dreamweaver was good for, but not worth using just for that.

NetBeans IDE offers syntax highlighting for CSS, PHP, JavaScript and HTML and nicely highlights errors within each language.

It’s my current editor of choice and I would not give it for the world.

NetBeans IDE is developed by Sun in Java and it is a really nice editor which I can envisage using for a very long time to come.

Being free and open source is also a very nice addition to the overall offering.

HTML-Kit

I have been using HTML-Kit for a long time now and it is by no means perfect, but it caters for the usual colour coding needs. It works fine with XHTML, CSS, JavaScript and PHP, which is a frequent mix of technologies I work with.

It also has an integrated FTP client which is nice for direct editing of files on a remote server, which is not an approach you want to take often, unless you are making quick tweaks to the content or simple changes. It works nicely on XP and Vista machines and is pretty fast.

The downside to it is the fact that it can be a bit messy with regards to indenting. It does not look particularly pleasing to the eye and it does not auto-complete code very well at all. It is suitable to those who do not like auto-complete (like me) and want a simple enough tool to do quick, high-quality work in it.

NotePad++

One of the biggest advantages of NotePad++ is that it doesn’t require installation – it runs off one small .exe file.

It is a nice editor, which handles HTML very well, but does not colour all types of code you are likely to work with.

I have also find this one to work slightly unreliably on Windows Vista machines (i.e. throwing up weird errors), which can be annoying.

Aptana

An editor much preferred by many interface developers for its auto-complete feature and the fact that it is a ‘sister’ of Eclipse, arguably one of those ‘industry standard’ editors liked by developers at Google and many big consultancies.

Aptana works pretty well on most machines and writing code in it is most of the time pretty nice experience.

It has AJAX library plug-ins which can help develop AJAX code faster. It handles code indentation pretty consistently and nicely and works very well for XHTML, CSS and Javascript.

It disadvantage is that its upgrades can cause constant hassles to developers as sometimes they do not work properly, so for every session you might find yourself having to ‘battle’ with an update that Aptana wants you to install, but it never can be done fully. Very annoying.

Apatana also does not work very well with PHP as it requires another extension for it (or another version of the tool). So it won’t colour PHP code nicely, which is annoying when you are intending to style up a Word Press blog or another system you might have developed using Code Igniter or PHP in general.

Eclipse

I find Eclipse to be a nice tool (sometimes more suitable than Aptana), but it is not one that was designed for HTML (hence it does not offer auto-completion – which can be perceived as an advantage by those who do not like auto-completion like myself).

Eclipse is nice and clean looking and tends to work pretty good. Also does not require installation so it can work nicely in those environments and circumstances where as a developer you do not have a permission to install a tool onto a machine you are developing on.

I have been in this circumstance many times before and Eclipse saved my life.

NotePad

Old, dirty and rudimentary, Notepad’s best feature is that it is featured on all Windows machines and it is simply there.

It can be a good tool for quick analysis of code problems and writing some quick proofs of concepts or testing a particular feature for cross-browser compatibility.

NotePad, of course, does not colour code, which is not usable for working on bigger and more complex projects, but for a long time I developed code using only NotePad and it is a tool which one can rely on to a great extent.

In some cases you will be asked to develop code in environment where you will not only be disallowed from installing tools on the machine you are working on, but also be disallowed from downloading new tools (like Eclipse).

You might find, in this case, that NotePad is the only option you have, hence it does no harm to be familiar with coding in it as well!

Blue Fish

Blue Fish code editor is available for Linux only, so if you are using Ubuntu or a similar Operating System, chances are you will settle onto using Blue Fish on that platform.

Blue Fish is similar to other editors and contains a feature like HTML Kit which allows the editor to be setup to directly edit files on an FTP server.

There’s no integration with SVN as far as I know like there is in Aptana (which is also available on Linux, but a bit tricky to install).

Blue Fish also allows changes to be made to the font faces which are used to display the code in, but you are likely to want to keep these to the most readable font face like in Aptana or HTML Kit.

Blue Fish is responsive and a good code editor and by far the best one I have come across on Ubuntu if you are looking for as close a development experience as on Windows while being on Linux.

VIM

Many people have spoken to me about VIM on Linux and it being a very versatile code editor.

However, I have attempted using VIM many times so far and have failed miserably at it.

The idea that a code editor required heavy training and reading in order for one to start using it really puts me off.

At the end of the day, the point of development is not to be learning to use the editor, but to develop great code.

Other HTML editors

Oxygen

I have heard from a few developers that Oxygen 8 (the last version I heard of) is a nice tool to work with.

It is an advanced tool which only costs $40 and offers nice tools and features for working with XSLT, XML and various transformation languages.

It allows you to create object oriented hierarchies of code and preview them in a usable manner. It also offers some useful transformation and testing features which make XSLT development much faster and more reliable.

XMLSpy

XMLSpy is a very good editor also, but much uglier than Oxygen and it is harder to use Oxygen’s features in it from what I have heard.

It is a nice and strict tool, which imposes development within UTF-8 character encoding and flags up all the XML non-compliance issues up front, forcing developer to be very precise and strict with their coding.

XMLSpy also is not a free tool, but it does not break the bank to buy of copy of it as I think it costs around the same amount as Oxygen.

Tags: , ,
Posted in Development, Intermediate | 18 Comments »

« Older Entries
Newer Entries »