WYMEditor HTML Textarea Loses Focus

January 24th, 2008 by Robert

I’ve been using the WYMEditor on a little content management system I’ve been building at work. I was having a problem where I couldn’t edit in the HTML editor. Every time I clicked, the HTML textarea in WYMEditor would lose focus.

It turns out the problem was the way I used my label for the textarea that turns into the WYMEditor. There are two ways to use label. One is to tie the element to a form element via for="element-id" where element-id is the id of the form element. The other is to simply encapsulate the form element inside the label. I was doing the latter since I had written CSS to display forms.

labels focus the corresponding element when clicked (or when elements inside them are clicked). If you click the element directly, the focus doesn’t change. What I was failing to realize was that WYMEditor was putting the replacement / overlay inside the label. The visual editor itself uses an iframe, which overrides the label. The HTML Editor portion uses another textarea. In FireFox, when I clicked the textarea to edit, the focus would shift to the hidden (and first in the code) textarea.

The solution was to use the for method instead of the encapsulation method for WYMEditors and modify my CSS.

Netscape Discontinued

December 28th, 2007 by Robert

According to the BBC, Netscape Navigator is being discontinued. Thank God.

The article goes over a brief history of Netscape. BBC left out the fact that the languishing browser has been the laughing stock of the alternative browsers for some time. The farce that was Internet Explorer Mode in Netscape 8 was the final nail in the coffin for me. Mozilla and, later, FireFox have been much better choices for alternative browsers since the Gecko rendering engine was unleashed, and Internet Explorer was arguably preferable in the Netscape 4 days (what the hell is a layer, anyway?).

Good riddance, Netscape Navigator.

Easier Image Replacement

September 24th, 2007 by Robert

If you didn’t hear, text on a website is better than an image. Images have their place, but many people use images where text should be. In recent times, people have been using a technique called image replacement to replace text with an image. Typically, there are crazy hacks that involve embedded elements, but there is an easier way.

Before I get to that, I want to clear up when I think it is good to use images and when it is good to use image replacement.

It’s good to use image replacement when the object in question is, simply, an image. For whatever reason, I always picture a horse, silhouetted against a brilliant pink sunset, running through a grassy field on cliffs above the ocean. What I did there was describe the image, which goes in an alt attribute. My rule for using images is: if the proper description is a sentence (or longer), use an image with an alt. If the proper description ends up being a few words (e.g. Amazon Logo), use image replacement with semantic markup.

Most of the time, fancy heading text (in h1s, etc) and logos are prime targets for image replacement. Logos typically appear at the top of the screen and, to me, seem to be the top-level heading of the site. Other times, people want their heading text to be in fonts that aren’t web safe. This is a great time for image replacement, because it retains the semantic value and accessibility without some level of complication (that is, the heading isn’t the alternate text inside an image, it’s just the text).

There are tons of ways to do image replacement. Until recently, I was doing it the way I think most people do it (sorry for the inline CSS; I’m trying to avoid confusion):

1
2
3
<h1 style="background-image:url(myheading.png); width:100px; height:100px">
 <span style="position:absolute; margin-left:-9999px;">My Heading</span>
</h1>

This is a perfectly valid way to do the markup. The only problem is that it has that extra span in there. It’s semantically valid (since spans don’t mean anything, but it’s one more level of complexity (that is, the heading is the text inside of the span), which is what we wanted to avoid.

Instead, I’ve been doing it this way1 (again, sorry for the inline CSS):

1
<h1 style="position:relative; width:100px; height:100px; clip:auto; overflow:hidden; line-height:210px; font-size:10px; background-image:url(myheading.png);">My Heading</h1>

The relative positioning makes it possible to clip and hide the overflow of the element. So, we set our height and width to that of the image that will replace the text. We then come up with a sane image height (I’ve used 10px because the text doesn’t have to resize since it is hidden and because the default don’t display text smaller than setting in browsers should be lower than this by default (if there is any worry, we can use a larger font size). Then, we set the line-height to the site of the image plus the size of the font (this seems to hide the font just out over the height of the element). Using the line height, we can also assure that the text will be hidden since it will be below the visible area instead of to the left or above it.

There you have it: yet another way to do image replacement. Is it better? Maybe. It reduces the complexity of the markup, making it less bloated and a bit more efficient, semantically if nothing else. However, it increases the work that needs to be done on the CSS side. With this we have a little math to do, and a little bit more to type. To reduce the extra typing a class could be created to handle the position, clip, overflow, and font-size with the second class setting up the stuff that changes per image. In the end, do what suits you best. I’ll be doing it this way.

As a warning, the only problem I’ve run into2 was if I set the line height too high, Internet Explorer would have some rendering problems. I don’t remember exactly what happened, as it’s been awhile since I tested this on a real browser. I’ll be sure to update this post the next time I am able to test.

  1. Wait! This is sort of untrue. I thought I was doing this one way, but it turns out I was wrong. I was using something with position: absolute, which has some positioning problems if the user is unaware of how absolute positioning works. I’m pretending I’ve been doing it this way because I like it better.

  2. Technically, it was a problem with the way I was doing the absolute positioned way. I’m leaving the warning in just in case for now.

Who the Hell is Domain Design Shop?

September 21st, 2007 by Robert

I ordered a couple domains from GoDaddy a few days ago. I wasn’t really surprised when I found an e-mail with the subject Important information about your domain. I was surprised at what was inside.

Hello,
Congratulations on registering the domain: [removed for privacy]. Now is the time to establish an effective Internet presence. Domain Design Shop is an internationally recognized Web design company that specializes in marketing and branding. Our staff has assisted hundreds of companies, organizations, and individuals in achieving their goals of developing custom web sites and technology solutions.

Please click here to see our portfolio: http://www.domaindesignshop.com

Warm Regards,
DomainDesignShop.com [email: domain@domaindesignshop.com]

I’m not sure if these people are spamming me from my domain record or if they are in cahoots with GoDaddy. I’m guessing the former. I really need to set up a domains e-mail account.

So, here is this design company that spams new domain buyers in hopes that they will hire them. That is a really bad way to convince people of your services. But what the hell? I’ll take a look at their site.

I am greeted with a punch in the retina by an alarmingly green monstrosity. As usual, I look down at the bottom left of my browser at SafariTidy’s output. 6 warnings on their home page. I click to open the report. Each warning is about depreciated or proprietary attributes. The code is tag soup, and table based. None of the images have alt attributes. So far, these guys are spamming me, and showing me that the product they would provide me is complete shit.

Then I noticed that the color of the background image didn’t exactly match the background color of the document. The header image’s background color does match. So, there are all kinds of slightly different colored blocks floating around. It’s this sort of lack of attention to detail that separates the mediocre from the great. They also have a weird gray drop shadow-esque thing that I can’t figure out.

The thing that shines on their site is their logo work. I wish they would have included some one-color proofs, though. Other than that, their work isn’t particularly appealing to me. It is average, overall.

And, finally, the ISO Best Web Design 2006 badge on their site is… well, tacky. They don’t even provide a link to a press release. For all I know, it’s a stock graphic. I’ve never seen any other ISO Best Web Design badges. Since it dates the site to 2006, I’m sorry to say that the work done is not up to snuff for real professional designers. The lack of standards, offensive color scheme, and lack of attention to detail all point in the direction of Don’t Hire Me (ignoring the fact that they spammed me). In fact, they ought to be hiring me (or someone like me) to catch them up to 2005.

A Good Design Doesn’t Just Look Pretty

September 20th, 2007 by Robert

A successful design doesn’t just look pretty. It communicates.

Recently at work, I had to review several websites to determine what category the business falls under. I found only one that clearly stated what the business did. All the others were written under the assumption that the reader knew what the business did. Since I had no idea, this was rather irritating. I came to the conclusion that one of the ugliest sites on my list was the most well designed.

Websites exist to communicate. A website that doesn’t communicate is poorly designed. So, a note to designers, make sure your copy clearly states what the business does on the home page (or something akin to an about us page) so that people that aren’t familiar with the company know what the company does without having to figure it out. Otherwise, people might do what I wanted to: close the site after 10 seconds of not seeing a clear description.

iPod Touch Pushing the Mobile Web

September 14th, 2007 by Robert

As most know, Apple released a new line up of iPods, and possibly a major improvement for the mobile web.

The iPod Touch is essentially the iPhone without the cellular radios. It has the same WiFi, runs the same operating system, and has many of the same programs. Most important is Safari Mobile.

A major stumbling block to the mobile web is the crappy and disparate browsers. Most don’t do very well with HTML, or, worse, only work with WAP. Programs like Opera Mini and the S60 Browser from Nokia have made great inroads for the mobile web. The release of the iPhone improve user interaction with the web in the mobile space.

Now the iPod touch will bring Safari Mobile to a more ubiquitous space. In a comment on The good, the bad, and the ugly – iPhone edition, I claimed that Safari would never be another Internet Explorer. I stand firm on that, as Safari Mobile is still niche, but it stands to be a much bigger play (and possibly nuisance if these iPhone-only sites perpetuate).

Whatever the case, the mobile web has no become more ubiquitous. I know for certain that I’d pull out my iPod Touch (if I had one) to browse the web with long before I’d reach for my mobile phone. The only drawback is the lack of a cellular radio. If Apple could work out some 3G radio for the iPod Touch to deliver data only and provide it with a very cheap contract, the mobile web landscape would change drastically.

iUI Makes iPhone Development Easier

August 17th, 2007 by Robert

The iPhone was a little less exciting when Apple revealed that web apps were the only way developers could write applications for the iPhone. While committed folks eventually opened the phone up for third-party applications, some interesting stuff was happening on the web application front. It’s called iUI.

iUI is a JavaScript framework to make coding pages for the iPhone really easy. Joe Hewitt’s (of FireFox, FireBug, and FaceBook fame) small JavaScript library can transform simple lists and links into an experience much like a regular iPhone application.

iUI uses many CSS3 properties with images ripped from the iPhone itself to create the distinctive interface, complete with sliding animations and Ajax page replacement. He points out in a Y!UI Theater video that Safari Mobile lacks many events found on regular browsers due to lack of ways to input those events on a touch screen, as well as having no mechanism to access flicks used to scroll in native applications.

Despite the limitations, knowing such an easy to use solution makes me want to download TestiPhone and write something for iPhone, even though I don’t own an iPhone. I would take Eric Meyer’s concerns into account, however.

So Long KHTML, Long Live WebKit

July 24th, 2007 by Robert

Once upon a time, there was KHTML, The K Desktop Environment’s Hypertext Markup Language rendering engine. Later, Apple decided to write a web browser. For whatever reason, Apple embraced KHTML, forked it, and created WebKit. There was much pleasure and much gnashing of teeth.

In mid-2003, Apple release Safari 1.0, ending the beta stage of development. The betas caused such a wave that Microsoft announced it would discontinue development of Internet Explorer for Mac (assuming they were developing it at all), and other browser developers made similar threats (i.e. Opera and Chimera). Meanwhile, other Mac browsers were reporting they would swap to WebKit. Needless to say, Mac users adopted Safari in droves, making Safari a major player in the browser space.

By 2005, however, Apple seemed to be shafting the KHTML team by not releasing patches, or releasing patches that were very difficult to merge into the main trunk, if they could be merged at all. This caused a bit of disdain in the open source development community (though Dave Hyatt queried for help on how to rectify the situation), but widely had no negative effect on Safari’s usage. Apple released WebKit, complete with version history, a few months later.

WebKit even crossed into the mobile space. The acclaimed WebKit-based Series 60 web browser from Nokia was released as open source, proving that WebKit was a viable rendering engine for mobile devices. Recently, Apple released the iPhone, which, of course, has a WebKit browser included. Safari Mobile builds on the concepts of the Series 60 browser, but easily one-ups it.

Yet, all this time, KHTML and WebKit have diverged, and were predicted never to merge. This prophecy held true. Recently, KDE decided to adopt WebKit and eventually remove KHTML after some final KHTML features are ported into WebKit. With recent additions to the WebKit family (e.g., Safari for Windows, Abrowse, Epiphany, and Adobe’s Air), all the major, graphical, desktop browsers will be united under the four major rendering engines (the others being the Internet Explorer Trident family, Gecko, and Opera). Also, TrollTech will bring WebKit into QT, which will allow the use of cross-platform WebKit integration with relative ease, hopefully countering the use of Internet Explorer’s engine in Microsoft’s development environments. I doubt this will swing WebKit to a much higher rank, but it certainly bodes well for the longevity of the project.

Easy Clearing Of Floats

April 24th, 2007 by Robert

Web standards designers often need to make use of display:float to handle things like columns, navigation lists, and more. Usually these floats are followed by something like <div style="clear:both"></div>. It turns out there is an easier way.

I was reading 35 Designers x 5 Questions and saw a link for a way to clear floats without clear divs. The code that comes with the article is a bit confusing and sloppily written, but it works!

So, to make things easier to understand, I wrote my own example. The code below will do it for you.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
 <head>
  <title>Easy Floats</title>
  <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
  <style>
h1 {
	background-color:#FFCCCC;
	margin:auto;
	width:500px;
	text-align:center;
	margin-bottom:0px;
}
div#outer{
	width:500px;
	overflow:auto;
	padding-bottom:0px;
	background-color:#AAAAAA;
	margin:auto;
}
div#column1 {
	float:left;
	background-color:#CCFFCC;
	width:200px;
}
div#column2 {
	float:left;
	background-color:#CCCCFF;
	width:300px;
}
div#footer{
	width:500px;
	overflow:auto;
	padding-bottom:0px;
	background-color:#FFCCFF;
	margin:auto;
}
div p{
	padding:10px;
}
  </style>
 </head>
 <body>
  <h1>title</h1>
  <div id="outer">
   <div id="column1">
    <p>
     Left
     <br>
     Column
     <br>
     Floated
     <br>
     Left
    </p>
   </div>
   <div id="column2">
    <p>
     Right Column float with no clears below it...
    <br>
    </p>
   </div>
  </div>
  <div id="footer">
   <p>
    FOOTER not cleared...
   </p>
  </div>
 </body>
</html>

Internet Explorer 7 Heading Bug

April 5th, 2007 by Robert

I try to avoid Internet Explorer 7, or IE7 for short, but I can’t any more. Today was the first time I really had to debug in IE7 and I discovered a pretty irritating bug.

What I wanted to do was put a h2 inside of a div and adjust the margin-top so that it was hanging over the top edge of the div. Imagine a fieldset with a legend.

My code and style sheet were something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<style type="text/css">
div {
	border:1px dashed black;
	background-image:url(../images/sect_bg.png);
	padding:10px;
	margin-bottom:25px;
	clear:both;
}
h2 {
	display:block;
	width:100%;
	height:53px;
	background-repeat:no-repeat;
	background-position:center center;
	margin-top:-33px !important;
	text-align:center;
	background-image:url(../images/blog_title.png);
}
h2 span {
	position:absolute;
	margin-left:-9999px;
}
</style>
<div>
 <h2><span>Heading</span></h2>
 <p>Some Text</p>
</div>

In IE7, nothing happened. In every other browser, the heading moved up. I started playing with the style sheet, removing parts. It turns out that the height and width were the problem. This applied not only to my image replacement, but a plain-old div-with-a-heading-in-it. The fix for my problem was to create a separate IE7 style sheet with the following:

1
2
3
4
5
h2{
	width:auto;
	height:auto;
	padding-top:53px;
}

I was also informed today that my Internet Explorer 6 Virtual PC image had expired. As promised, Microsoft has released a new Virtual PC image. While it’s nice to be able to check against Internet Explorer 6, this refresh cycle isn’t very convenient.