Feature: HTML5 supportDeveloper: NaoTarget: themers, modders, usersStatus: 95% (complete, but by definition this will never be finished. Also, support in progress in media area.)Comment:

Adds full support for the HTML5 specs in Wedge (except where XML compatibility is required: XML queries, wireless, etc.)Most notably, IE 6/7/8 users automatically get the 'html5shiv' shim which enables styling the new tags. The default theme uses some of these tags as well.To save bandwidth, all self-closing tags were updated to use the simplified syntax (<br> instead of <br />, etc), deprecated attributes (type=text/css, type=text/javascript...) were deleted, and valueless attributes had their XHTML value removed.All pages fully validate the experimental HTML5 validator at validator.w3.org. If you ever find a page that doesn't validate, make sure to tell us -- we will promptly fix it.

Many SMF mods tend to add jQuery headers to ease their work in the JavaScript department. They would tend to conflict with each other. Add to this various mods that make use of other librairies, and it's become clear that Wedge really needed to have jQuery by default, so as to provide a standard library for all modders.Wedge offers to load the jQuery library from three different sources: local (if you want to use your own server to provide it and don't mind the extra load on your bandwidth), jQuery CDN or Google CDN. We recommend the Google CDN, which is the most reliable source for providing jQuery. In addition, it always loads fast, and chances are that the library will already be cached on your computer if you tend to visit other websites that also include jQuery from the Google CDN.We strive to make Wedge compatible with the latest jQuery, but we're currently staying on the 1.5 branch, until they do something about their oversized library. ;)

Feature: Removing deprecated codeDeveloper: Arantor & NaoTarget: admins, modders, themersStatus: 99% (believed to be complete, but it's a never-ending feature implementation because of its very nature.)Comment:

We believe that software should live in the present, not in the past. Libraries that were deprecated years ago should not be supported anymore, because they mean overhead, bloat, and usually prevent developers from using new features, for fear of breaking something on older platforms. Because some people are too afraid of "fixing what isn't broken", they're still using PHP 4.x and MySQL 4.0 these days.They shouldn't be afraid.So we removed support for PHP < 5.1.2, MySQL < 4.1.2, and are requiring support for the GD2 graphics library (which shouldn't be a problem in 99% of the cases.)Dozens of other minor libraries, functions and programming methods that didn't belong in this age were also deprecated, such as support for the Wap, Wap2 and iMode wireless modes, the boardmod installation system for add-ons, or older SMF1 compatibility code.

PostgreSQL and SQlite are great database systems. But they just aren't used that much, and they add more complexity to database development in SMF. Wedge continues abstracting database queries, but doesn't attempt to convert them to another SQL language.From our experience, users with PGSQL or SQlite installed on their server always have MySQL installed as well. If you really don't, Wedge just isn't for you, but we won't go back to applying patches for systems that no one really ever uses. It makes development tedious, longer, and probably insecure.

SMF was celebrated for supporting all possible charsets in its codebase. This was back in 2003. Work on SMF2 was started in 2005. Six years later, UTF8 is supported everywhere, and text string size is not really a problem anymore.We decided to drop support for all charsets and force the use of UTF8 everywhere. Ultimately, this will be a blessing to modders who always had to make sure their string manipulation routines was using the correct charset path.Also, $smcFunc functions were slow, we worked on their performance when moving them over to the westr object. Generally speaking, everything should be made easier with this move. It's time to say goodbye to ISO-8859-1.

SMF uses the infamous $smcFunc array structure to store pretty much anything that should be dynamic functions.Wedge replaces this with object structures, mostly of the singleton/static types. Basically, Wedge objects start with the 'we' keyword, generally followed by a three-letter code representing whatever feature it's about.Some of the objects include: we (holds system and user variables such as we::$id for the user ID), wesql (database abstraction, e.g. wesql::query), westr (string functions, e.g. westr::substr), wecss (CSS pre-parsing), wedit (the WYSIWYG editor), and wetem (the main template skeleton).

They say beauty is in the eye of the beholder. Let's be clear, the SMF codebase would already enchant any given geeky beholder. Really. Just have a look at any other popular forum/blog platforms. Their PHP, HTML, CSS and JS are often at best acceptable, at worst unreadable. Wordpress says that coding is art. Well, if you looked into their code, you'd swear they meant talking about modern art.SMF doesn't have this problem, because it's been mostly maintained by anal-retentive genius coders. Only problem -- I'm even more anal-retentive than they are. So, every time I find some code that I feel is sub-standard, I'll just rewrite it. Sometimes the code is micro-optimized in the process, mostly it's just prettified.Some changes are project-wide (making sure that all files are saved in LF format as opposed to CRLF, removing useless {} or extra tabs in empty lines or at the end of lines), most are way more specific. Let's not delve into that too much. You might find I'm a bit crazy in that area. I changed thousands of lines just because they looked ugly to me.

jQuery adds about 31kb to your content the first time you load it. But you may not even realize it: we load jQuery from Google by default, and if another website does the same, chances are the file is already in your browser cache and doesn't need to be loaded.Still, I'd rather take the worst situation into account and say you're on a 56kbps modem and your browser cache is disabled. You have a right to be silly, we're not judging. So, I solved this problem by saving space everywhere else, optimizing every single bit of SMF's JavaScript code, and using jQuery everywhere it made sense to use it.For instance, the script.js file in SMF is about 47kb, while the Wedge version clocks in at 27kb. All of the JS files were optimized in a similar fashion, resulting in smaller files, even with jQuery thrown into the process. See the code that applies CSS to the WYSIWYG editor in SMF2? 74 lines. In Wedge? 2 lines. Two.One of the better aspects of using jQuery in the JS files is that we can also take advantage of its superior capabilities. Sometimes, it will simply replace advantageously an existing feature. The news fader script is 6.6kb in SMF, and 1.6kb in Wedge, with the same outcome.Other times, I added some nice bits to the SMF formula. The infamous toggler is now much shorter and adds a nice animation effect. We also have the reqWin function. It's called whenever you click a help icon to show a popup with some help text. The Wedge version of reqWin actually opens a div popup with fixed position, with the ability to move it around the page. It works just as well as the SMF version, is non-modal, has some nice subtle visual effects, and frankly, did you ever like SMF's window popups anyway?There are plenty more examples of the advantages of using jQuery in the JS files, but you'll have to find out for yourself...