November 1st, 2007 Posted by Don Albrecht
Yesterday, We explored the jQuery Dimensions plugin and how it can be used to get a handle on the Physical location of elements on the page. Today we explore achieving the same effect with the native Prototype Element & Position Objects.
Element provides three methods to get a handle on the dimensions of an element
- getWidth( element ) Returns the width of an element
- getHeight() Returns the height of an element
- getDimensions() Returns the height & width of an element as an associative array.
For more advanced and capable access to the spacial properties of an Element we turn to the Position object.
- page() Returns the x, y position of an element relative to the viewport
- cumulativeOffset() Returns the x, y position of an element relative to the entire document
- positionedOffset() Returns the position of an element relative to its parent.
As you can see, the prototype tools are a bit more powerful out of the box than jQuery Dimension (None of these require a plugin.) Prototype, however, doesn’t handle scrolls as well as jQuery Dimension.
Read more about these APIs at
http://www.prototypejs.org/api
October 29th, 2007 Posted by Don Albrecht
Mozilla has just released a prototype application called Prism. It streamlines the creation of a Webrunner app through a simple wizard. Great for getting your feet wet with Webrunner development or exploring the concept of offline use. You’ll still need to write a custom webapp to deploy however.
Prism is currently Windows only, but a mac version seems to be in the works.
Find More Information
http://labs.mozilla.com/2007/10/prism/
October 25th, 2007 Posted by Don Albrecht
Lightbox & CodaSlider aren’t compatible. A situation that was brought to my attention while participating in the comments on a blog post at http://www.ndoherty.com/. Conflicts like this are a common experience for many of us and I thought this was a good opportunity to explore the cause of one such conflict.
In the case of Lightbox & CodaSlider, the fundamental frameworks were at odds with each other. Lightbox is built with the Prototype / Scriptaculous framework stack, CodaSlider uses the jQuery framework. Superficially, this doesn’t seem like a big deal. While it’s usually bad form to load down a web page with multiple frameworks, I know it’s a crime many of us have been guilty of in the name of expediency or through multiple vendor integrations. Usually this works, but in this case, the developer was attempting to integrate two widgets that were instantiated at different times and by different methods.
Luckily, there’s a simple solution to the problem. I directed her towards the popular “ThickBox” widget instead. In fact, that’s the greatest strength of the Ajax Bestiary we all have at our disposal. There’s usually another tool available for us to use and in the case of popular frameworks like jQuery, a native solution is out there. So if you ever find yourself in this situation, try to find the native solution.
October 24th, 2007 Posted by Don Albrecht
Let me start by saying that I love CSS frameworks. From Tripoli to Blueprint, YUI to YAML, I’ve embraced them fully into my design and development process over the past 9 months. Unfortunately, throughout that time I’ve had to deal with a nagging issue: The Semantic Web.
CSS exists to shed the shackles of inline formatting and truly separate content from display. While It’s rarely possible to achieve all of a project goals in a semantic way, CSS frameworks really fly in the face of a semantic approach. Don’t get me wrong, I still think CSS is the way to go and that frameworks provide powerful scaffolding, but I think we all need to be aware that using CSS grid & layout frameworks isn’t exactly a true separation of content & styling.
Take for example, blueprint. Blueprint contains a powerful set of tools for building a layout. Unfortunately, these tools require that columns be explicitly defined in the page source <div class=”column span-2″>. This makes it impossible for a change in stylesheet to completely alter a page layout for mobile devices without discarding the column & span classes and relying on an independent set of markup e.g. <div class=”column span-2 mobile-column mobile-span-5″>. This is a rather cumbersome noose to have to carry for some projects. Especially when the infrastructure isn’t in place to deliver two distinct versions of the site from the server.
I’m wondering how you have addressed these problems in past projects?
August 14th, 2007 Posted by Don Albrecht
Here are 5 open source WYSIWYG editors you might consider for your upcoming development projects. Rich Text Editors are one of the workhorses of modern web applications. Providing simplified wysiwyg formating of content for forms, RTEs have become a favorite among users.
Tiny MCE stands out as the most popular of the modern editors. The high flexibility, simplified theming and extreme ease of use the editor provides are highly regarded and well praised. Some key features:
- Microsoft Word Cleanup Filter
- Ability to fine tune available buttons
- Ability to restrict html to certain css styles
- Excellent Media import tools
- Simple API for custom features
- Skinable
A venerable successor to HTMLArea, Xinha combines flexibility with a slick interface. Although once relegated primarily to the Zope / Plone universe. Xinha has lately emerged as a powerful stand alone editor. Many developers prefer its media & css tools to those of Tiny MCE
- Microsoft Word Cleanup Filter
- Highly Configurable
- Ability to restrict html to certain css styles
- Powerful Media import tools
- Skinable
Although still popular, FCK editor doesn’t compete as well against the top tier wysiwyg editors as it once did. The interface seems clunky, especially compared to Xinha or Tiny MCE. And there’s always the issue of the name, I’ve had it shot down from a project spec because of it. The software is included here out of completeness and the fact that it is still widely used and adopted.
- Extensive capabilities
- Established & heavily deployed
The Dojo Editor Widget is an integral part of the Dojo Ajax Toolkit. It is included here because of the compelling features that make it unique. Chief among these features is the ability to share one toolbar across multiple editor instances. It is this ability to provide a traditional application toolbar feel when multiple editors are in use that sets the Dojo Editor apart and inspired me to include it here today.
- Skinable
- Shared Toolbar Support
- Powerful API
Finally, an editor that works in Safari. Built on the YUI toolkit, the beta form of the Yahoo Rich Text Editor was designed from the ground up to work in Safari. By coding for Safari first and then modifying the code to create something that worked in Opera, Firefox & Internet Explorer. Dav Glass created a cross platform editor that surpasses every other editor in this list for browser support. The other unique feature of the YUI editor is web 2.0 / Mashup support and integration. By integrating a unique Flickr photo picker & useful insert link tools the YUI RTE has emerged as a force to be reckoned with in the WYSIWYG world.
- Flickr Photo Picker
- Link Picker Tools
- Powerful API
- Skinable
- Safari Support
August 13th, 2007 Posted by Don Albrecht
There are two extremely powerful CSS frameworks available to web developers at this time: blueprint & yui css. Both provide a basic css reset, simplified font formating & powerful layout tools. It is the layout tools that will most influence your decision as to which framework makes sense for your project.
Blueprint is based on a strict layout grid. All objects are defined in terms of 14 columns that define a 950px wide layout. Complex layouts can be defined by carefully constructing columns & collections of columns. There is no limit to recursive depth, however no column can be less than 70 pixels wide and all columns are a multiple of 70 pixels. This ensures that everything on the page lines up cleanly.
YUI uses a more flexible template & divider route. All YUI layouts begin as a document with a predefined width ( 750px, 950px, 974px, 100% or a custom width). A single sidebar can then be added to the left or right in a predefined width ( 160px, 180px, 240px, 300 px). Lastly, the body can be recursively divided using grid tools into thirds, quarters & halves.
So, which one should you use?
Use YUI if you need a layout in a dimension other than 950px or if your layout requires division by thirds or quarters across the entire width.
Don’t use YUI if you need to create objects that are a width other than 2/3, 1/3, 1/2, 1/4 or 3/4 of their container e.g. (5/6, 7/8) or if you need more precise control of dimensions.
Use Blueprint if you need fine grained control & precise positioning in a standard 950px layout. Generally, Blueprint based layouts are much more manageable over the long run & easier to code. Unfortunately they have higher bandwidth consumption & fewer options than a YUI layout.
Latest Posts