Beast-Blog.com
Coding & Markup

Many web developers who blog at some point share a little code or scripting. We do this to give away a hard-earned/hard-learned tip or trick, or in some cases to offer a whole script or code solution. We try to make the Internet a better place. This is a great thing about the web, all this openness and sharing over the years. I’ve observed over those years, though, that some post code more effectively than others. I’ve seen code posted on the web that was hard to read, difficult to access, and sometimes nearly impossible to use. Based on these observations, and based on my own personal preferences in some instances, I have come up with the following tips for posting code online.

Continue reading “Tips for Posting Code Online” »

Local brick-n-mortar businesses, those who rely on walk-in, on-location commerce, will often have a web site to promote their business. It’s a good idea. The cost of having a web site is next to nothing, maintenance is easy if the site was built with updating in mind, and it can be a great service to existing and potential customers, depending on how it’s used. One such service would be helping the potential client find the business’s physical location. This can be easily facilitated by adding a location map to the site. How one should do this is the subject of this article.

Continue reading “Adding a Map to Your Web Site” »

When I made my How to Build a CSS Web Site tutorial I purposely started with a valid and well-formed, but unstyled HTML page — within the tutorial’s styled page (tricky). I then applied styling gradually, seen as the tutorial runs. The Cascading Style Sheet (CSS) additions are marked on the example text “File” for each page. By the time one gets to page twenty the template is done, hack-free, and the style sheet is complete. I didn’t use universal resets in this build, so I really just whipped a couple of elements into shape with as little styling help as possible. I let the browsers do their thing instead of butting heads with them. During this element whipping I also “tweaked” list types in this template (on page 18). It’s this I want to point out because I think its works well, especially for the minimalist.

Continue reading “Tweaking Your Lists” »

I am really impressed with the HTML 5 work being performed by Ian Hickson, as the draft editor, and the others who are part of the WHATWG. I’m a fan of the work, and I believe it has promise. From the updated meaning of some of those gray area elements, to the deprecation (made obsolete) of some of the garbage that has littered the web for the past fifteen years, to the introduction of new elements that will offer organizational value where none exists today, to the introduction of new attributes to give all elements clearer meaning, it all bodes well with me. But I cannot help but wonder how we will get there.

Continue reading “Will the Road to HTML 5 be Rough?” »

The HTML 4.01 specification defines the “phrase” elements em and strong as indicators of emphasis and stronger emphasis, respectively. The XHTML specification doesn’t change this, it only demands the use of closing elements and proper nesting. These definitions, though, leave something to be desired. Is “stronger emphasis” an inflected inflection?! Is it used when you really, really mean it? Do you add two exclamation points just to get the point across? I don’t like any of those options.

Continue reading “Using the HTML Em and Strong Elements” »

Misusing specific elements in a way not intended, especially for presentational purposes, while creative and admirable on many levels, simply isn’t right.

A number of years ago some members of the scientific community and the United States government were involved in a new way to share text and data documents over phone lines. This became the Internet. It didn’t take long for people, call them web designers, to adopt and subsequently exploit this technology by using and even misusing the use-specific elements interpreted and rendered by “web browsers.”

Continue reading “Are Lists Becoming the New Tables?” »

Not too long ago I wrote an article on keeping forms accessible. That was in September of ‘07. It’s an okay article, mostly accurate and helpful. I’ll stand behind its recommendations (it’s not that old), but one of those recommendations, an allowance actually, is seriously flawed. I am compelled and obligated to correct this. You see, I learned that a normal form-building practice of mine — wrapping a form input with its label — can seriously impact the accessibility and usability of a web form. Like hiding an input under a blanket.

Continue reading “Inaccessible Label-Wrapped Form Inputs” »

This practice, while it does carry risks, like most things we do, can be successful, but it must be used intelligently and in moderation.

My friend and colleague, Mel Pedley, brought up a point recently — as we were discussing a site being graded at Accessites — about hiding text for screen reader users using an “offset class,” where one uses absolute positioning to send the element outside the viewport, usually by thousands of pixels. Our grading discussions are under lock and key, available to the team members and site submitter only, so there’s no sense providing a link, but here’s an excerpt:

Continue reading “Hiding Content for Screen Reader Users” »

Ever since I have been flying the web developer pennant in my occupational corner I have been trying to develop my own best practices based on existing web standards and accessibility requirements, and then applying them consistently. My goal is to gain the ability to perform a task the same way time and time again without having to think about it, meanwhile ensuring my works conform to standardized usability practices to guarantee at least satisfactory experiences for my site’s users. Consistency, after all, can be a very good thing for everyone. Let me explain.

Continue reading “The Joys of Consistent Web Practices” »