It’s no secret that I adore my Mac, mostly because it just makes my life easier. I enjoy the security of OSX, I love it’s responsiveness and I love that my operating system doesn’t punish me for installing applications and development stacks just to ‘play with them’. A while ago, while looking for a stack that would let me quickly and effortlessly get Apache, MySQL and PHP5 working together without having to muss about with configs and the such, I discovered MAMP and frankly, I adored it instantly. After a rather large download, it was effortless to install and running it was a cinch. And better still, the server applications only run when you open the MAMP application and tell them to run, so that you dont loose vital system resources running services you dont need.
Additionally, my IDE of choice, NetBeans can integrate directly with MAMP, so that when you create (for sake of argument) a new PHP project and run it, it automatically puts the project files into the MAMP Apache directory (to be honest you do need to configure the path when you create the project, but its no big deal) making development painless and convenient.
But I did hit a snag recently when for a university assignment I was required to do a XHTML website using HTML Server Side Includes. I was shocked when I ran my website and my SSI didnt work.
But there is a solution.
To make .shtml work, I deleted the comment-symbols ( # ) in the file http.conf (find it in /Applications/MAMP/conf/apache/ and at the time of writing was near lines 982:
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
I saw this tweet today:
#IRONY RT @kevinmarks: I like this ‘what is HTML5′ Infographic: should b a webpage not a bitmap
Now I repost here, in the event it should disappear because I think this is a really good info-graphic and it deserves more exposure…I hence present “WTF is HTML5 and why we should all care”.
The original link can be found here.
Thankfully, many of the popular browsers of today support the ability to rotate HTML elements. Even better? Wed can make it work in Internet Explorer (back to version 5.5 even). For Webkit and Firefox (as of 3.5), you can take advantage of the proposed
transform property to handle the rotation. Each browser requires its property prefix for now.
In order to perform a transformation, the element has to be set to display:block. In this case, just add the declaration to the span that you want to rotate.
When it comes to effects in Internet Explorer, there is a surprising amount of power (and untapped at that, I’d say) in using filters. Although misleading, there is a filter called BasicImage that offers up the ability to rotate any element that has layout.
The rotation property of the BasicImage filter can accept one of four values: 0, 1, 2, or 3 which will rotate the element 0, 90, 180 or 270 degress respectively.
Recently, I have been doing a lot of Model-View-Controller work in ASP.NET which has caused me to have to use some more “old school” style HTML controls, instead of the .Net Server-side Controls I am so used to. I came along an interesting problem where I needed a text area which automatically changed it’s height to fit all the text in without a horizontal scroll bar, much like Facebook does with it’s wall.
If you have a textarea, with the wrap=”off” attribute set, then its even easier. Just replace the script tage above with this one:
Cross-posted from the Particls blog.
For those of you like me who are too stubborn too busy to move to Gmail; our worse nightmares have been realised. Microsoft Outlook (whom consumes approximately ¾ of the corporate world’s email client market) will no longer render HTML emails with Internet Explorer, but instead with the crippled Microsoft Word HTML Engine.
I read David Greiner’s post on the Campaign Monitor Blog, and I agree with his sentiment totally.
After picking up the contents of my desk off the floor and taking a few deep breaths, I tried to come up with a few decent reasons why Microsoft would go in this direction. Here’s what I came up with.
Security – But wait! Microsoft have touted Internet Explorer as “a major step forward in security”. Surely they’d just replace the IE6 rendering engine with IE7 and be done with it. I’d also love to know how float and position impacts the security of an email in any way.
Consistent rendering – By default Outlook uses the Word engine to create HTML emails, which it’s done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they’d display emails using the same engine that created them. But what about the millions of other email newsletters out there that aren’t created with Outlook or Word? If an email is created with Outlook, then surely it should display perfectly in a modern browser like IE7.
They hate us – OK, this one might be pushing it, but I’m running out of explanations here. Don’t get me wrong, we’re not Microsoft bashers here. Both our products are developed on Microsoft’s .NET platform and we’ve been a fan of their development environment for the better part of a decade. But seriously, they’ve taken 5 important years off the email design community in one fell swoop.Without entering the Plain Text/HTML debate, there is simply no sense to Microsoft’s Product design decisions lately. I think we’re starting to see what happens in the IT marketplace when it takes a company too many years to release new versions of their software.
They claim that they are going to start itterating faster yet we have not seen any evidence of this so far.I personally needed Outlook to load faster, use less CPU/Memory and respond far, far faster than it does. I didn’t need its HTML rendering handicapped. Like I said, Microsoft seems to be failing me in areas it used to excel.