Aug
12th
For a couple of years, I'd been running an active forum for my Open Source projects. Years back, I'd chosen simple machines forum (better known simply as SMF), because of its features and the fast development progress it had back in 2005, prior to its first official release.
SMF was free, but not Open Source. It was kept under a proprietary license that disallowed the distribution of modified versions of the software. For me, this was never a problem, because I had no intention to distribute anything and local modifications (for your own use) were not prohibited. With the release of SMF 2.0, this has changed and SMF is now licensed under the modified BSD license, so it is as free as a piece of open source software can be.
In the last two years, some not so nice things happened at SMF. I do not want to go into detail here and, to be honest, I cannot, because I do not have enough knowledge, but everyone who was frequently following the SMF community probably knows that some things weren't always quite right over there. In short, there was a lot of fighting and arguing over mostly political and legal things, that's all I know.
However, from a developer's point of view, these issues are now settled. The code is out, it's open source and this is really all that matters for me. So I decided to play around with and create something new from it, adding a couple of new features, fixing a few annoying issues and - most importantly - giving the software a new, fresh and modern theme.
This has just started. Really, it's just about 2 weeks old, and it is really far, far, far from being a usable product, but it's a start.
If you are interested, you can follow it here.
Jul
20th
Everyone who has been using jQuery knows the purpose and how to use the jQuery(document).ready() function. But what if you want or need to implement such a construct without jQuery (for whatever reason, one would be to avoid the jQuery overhead if all you really need is the ready() handler?
One would think it's as simple as using a onload event, just like:
<body onload="myReadyHandler();">
But it is not. There is an important and significant difference between onload and document.ready():
Read more...
May
29th
How do you deal with JavaScript?
 Loading ...
A couple of days ago, I had one of these discussion with a good friend, who is - like myself - a typical "IT guy". Many of his opinions can be seen as fairly "old school", but he does have a lot of experience, particularly with network security and the evils of the Internet. I would say, he is a highly qualified expert in that area and he certainly knows his stuff.
While browsing my site, he noticed that it recently has become quite heavy on JavaScript with all the things I integrated, particularly the colorbox script, the syntax highlighter and some jQuery stuff. I know, he is not a fan of script heavy sites at all and he prefers to surf the net with JavaScript disabled by default.
Read more...
May
12th
Quick writeup with some helpful hints for migrating a WordPress theme to HTML5.
HTML5 is the upcoming standard for web documents, that's already set in stone. While the standard has not yet been finalized, it already looks very solid and consistent. One should expect some changes in the future, but don't be afraid you'll have to rewrite your entire theme when you make it ready for HTML 5 now. It's already safe to use and when done right, there will be no disadvantages, even for visitors who are not using one of the latest generation browsers.
Advantages
Keeping up with current or even future web standards is basically a good thing. By doing so, you gain access to new technologies and methods to create better web sites. You also ensure your sites will display with the same level of quality on many modern browsers and other web-enabled devices, because most of them are already supporting the new standard. There is a good level of backward compatibility, so using HTML 5 will not break your pages for visitors using an older browser that does not support it.
Read more...
May
4th
The problem
Firefox users who have the browser configured to not accept 3rd party cookies (which is the default setting, I believe and makes sense from a privacy point of view) may encounter a serious issue when using embedded Facebook Like or Recommend buttons. Clicking such a button can result in a loop, constantly trying to open the Facebook popup window. The only way to get out of this loop is to close the tab or window - obviously not very user friendly and a situation that might appear scary to less experienced users (it does suggest possible malware activities or a serious flaw on your site).
Read more...
Apr
30th
Fonts are a matter of personal taste, especially the size. People are different, some prefer smaller sized text, others can't stand it. Visitors have different browsers, are using different screens, different resolutions, DPI settings and even different zoom levels and if you are using a non-standard font for your page, browsers might have to substitute it with an available font. No matter how carefully you select the font and its size, it will most likely not please everyone. Allowing visitors to quickly change the text size and remember their preference is convenient and can improve reading experience.
The goal(s)
- Allow visitors to change the font size of articles in a convenient way, providing 2 simple buttons to increase or decrease the font size.
- Save the selection to a cookie, thus making it persistent for later visits.
- Make it look nice so that no ugly and disturbing page reflows happen due to changing the font size after the page has been loaded.
- Use jQuery where possible.
First, I only want to change the font size for the actual content. The header, footer and sidebar should not be affected, only the posts and pages, because this is what people are actually reading and where text size matters most. This is fairly easy to achieve because most WordPress themes use a wrapper class for posts, so it should be sufficient to change the font size for this class. For my theme, posts and pages are wrapped within a <div class="post"> and the actual content of the post (the article text or excerpt) is wrapped into another <div class="content">.
Read more...
Dec
9th
Styling <pre> and <code> tags can be cumbersome at times, especially when you use them for displaying content with arbitrary line lengths.
Source code of any kind and language is a good example here as it may contain overly long lines. Wrapping them inside <pre> or <code> tags has the potential of "blowing up" your page layout, because the browser will normally not reformat the content of a <pre> or <code> tag (pre stands for preformatted). This is especially annoying in forums or blogs because it will force readers to scroll the entire page horizontally and will generally look fugly.
Nevertheless, code blocks are important for many types of content - posting code examples, log files or anything else that contains pre-formatted textual data and almost any forum, blog or CMS allows for special formatting of code blocks.
Obviously, it is desirable to find a way to avoid these layout problems and there are basically 2 possible solutions:
Read more...
Oct
30th
After quite some time without any updates, I finally found time to take care of my aging Wiki. Because of some troubles (mainly bad performance and some old and no longer maintained extensions acting up), I decided to switch from MediaWiki to PmWiki and I'm loving it. PmWiki's simplicity paired with its powerful feature set is quite impressive, to say so.
The transition went with relative easy (with the help of some perl scripts to convert some of the markup differences between MediaWiki and PmWiki) and most of the pages are already online. Links should be fixed, but some orphans may still be straying around.
At the same time, I'm currently updating the TabSRMM documentation for version 3. Because of the many changes in the plugin, this is a lengthy process and it may take a while until I can finish it. The most important things are already done though.
Because of the different page organization system in PmWiki, some URLs had to change and the direct links in the TabSRMM option page may result in a 404. When possible, I installed redirection pages and I already updated the "Help" links in the plugin.
Apr
3rd
This was bothering me quite a bit lately. Embedding videos is fine, but the HTML code offered by YouTube has one flaw: It will make any validator throw a bunch of errors on your site, because YT is still using the <embed> tag, which is deprecated since XHTML 1.0 and should not be used any longer. All its functionality is provided by the <object> tag and any XHTML compliant code can therefore only use <object>.
Validation errors are not nice
Now, I know, a lot of people and web designers don't give a damn on whether their code validates cleanly, but I do, so I had to find a solution for this annoying problem. Read more...
Mar
26th
While building this site, I stumbled over a small problem regarding proper picture scaling with CSS. The original template had a simple scaling for the comments display which scaled any avatar to a fixed size of 48 by 48 pixels. Non-square avatars were, of course, looking a bit strange because of this scaling method.
User pictures are usually small, but restricting their size too much is not always the best idea. Some people insist on a certain level of “quality” for their user pictures, so a size of at least 100 by 100 pixel should be allowed for a profile picture, unless you really need to care about traffic a lot.
Now, 100 × 100 is fine for the profile or other locations, but for forum posts and especially comments, I would consider a 100 × 100 sized user picture too large. But when the pictures themselves are larger than – say – 100 × 100 pixels, you must dynamically downscale them for certain places of your site. Read more...
|
|
