One thing I love about working the web is the opportunity to find new solutions to problems. Sometimes, though, I just find a new solution to a problem that doesn’t exist. In my last post, I shared a solution I worked up to replace a few background pngs with CSS gradients. I was using a CSS gradient to create a sharp line by putting two color stops together. It is nothing new, really – people have been doing stripes with CSS gradients for a while.
What is neat about this process is that you can effectively run-length encode a row of pixels using CSS gradients with stops. If you manipulate the background-size and background-position attributes and add multiple background gradients, you can then create an entire image. Otherpeople have done similar things with box-shadow hacks, but I’m not aware of anyone doing this with gradients.
A word of warning – this is a really stupid way of rendering an image. Incredibly stupid. Don’t do it. It is huge, difficult to program, and turns my macbook pro into a hairdryer when rendering. The only thing I could see this technique possibly work for is maybe email marketing – but we all know that you do horrible, bad things with html in emails.
This entry was written by Kyle, posted on May 4, 2012 at 11:05 pm, filed under css3. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
Okay. I know setting style inline is bad in most cases. Keep your styles in your CSS file, your HTML in your HTML file and your javascript in your js file. CSS vendor prefixes are bad too. However, some cases dictate breaking some rules.
Right now I’m working on another game. Some elements of this game make use of multiple backgrounds and images that change color depending on the game state. The problem is that half of an image might be one color and the other half a different color. As I started proving my concepts, I used a background image that had the image details and another background image tucked behind that had the colors. This worked well enough, but to achieve some states, I would have one game element with three background images – too many http requests and hard work to render.
I realized that the image(s) that provided my split background colors could be replaced by a single CSS3 gradient. Nice! Because I was changing with the game state and I could have hundreds of different combinations of background details and background colors, using CSS classes would be impractical and a nightmare to maintain. I needed to set the style inline with Javascript. I realized that those darn prefixes could cause a problem.
In a CSS class you might have something like this:
This is fine for something declared in a CSS file. When parsing the CSS file the browser will just ignore all the other junk and find the syntax that works and ignores rest. When you try to do this with inline styles through Javascript, you’re having to manage a lot and cause quite a bit of work for the browser. Considering that this operation would happen hundreds of times over the course of my game, setting all these vendor prefixes were out of the question.
My first thought was “Hey – can Modernizr detect this?” Not really – at least not out of the box and Modernizr is pretty heavy if this is the only thing I’m doing. But I wanted some of this type of functionality. I know that when you try to set a style and the browser doesn’t understand it, it just ignores it. So, doing something like this in Mootools:
$('someElement').setStyle('background','-notvalid-gradient(red to blue)');
alert($('someElement').getStyle('background'));
Would result in a blank alert (not undefined or -notvalid-gradient(red to blue)) – expanding on this, I can figure out what syntax(es) are understood by the browser by testing each syntax once per session. I put together this jsfiddle to show how to detect CSS3 gradient syntaxes. You could even expand this to deal with other non-standard prefixes in a pinch.
A couple of notes – the order which this is evaluated is important – the webkit old syntax(-webkit-gradient) is evaluated before the current standard syntax – this means that only browsers that need the old syntax will use it. Also, the prefixless syntax is last – so in the future, when browsers support this, it will be used. This is also a relatively expensive test cycle – absolutely do this only once and cache the result to use throughout the session. Better yet, store it in a cookie or something so it doesn’t even need to be done each page load.
This entry was written by Kyle, posted on April 29, 2012 at 11:35 am, filed under css3, javascript. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
OpenID is grand. I use it in m.easur.es and I use it for some internal tools. You don’t have spend time writing a user administration logic and users don’t have know another password/user name combination. However, it doesn’t come without it’s perils.
For my host, I use HostGator. It is cheap and reliable. On a shared plan, however, it does have a few limitations. One being that the use mod_security which limits a few things, things like URLs being passed in a GET query string.
I lost an entire night of my life debugging why, suddenly, my OpenID based project stopped working. It all started when I logged into one my tools and I got a WordPress 404 page. Why? I hadn’t the foggiest. My first thought was that WordPress was somehow seeing this tool (which is a sub-directory off of that blog) as a post and rewriting it. So, I made a few modifications and moved the tool to a subdomain. Then, it just wasn’t working. I would attempt to log into the tool and it would just send me back to the index page but keep the URL would have the OpenID return query string. WHY?!
I fired up Chrome Developers Tools and noticed that I was getting a 403/Forbidden in this situation. I remember, then, that I had some problems initially my first OpenID project to a production Host Gator server and giving 403/Forbidden page. This became so confusing because I later realized I didn’t have a 403 error page defined for that subdomain, so it was redirecting back to the /(root) of the domain but the URL remained the same. At least I knew what my problem was at this point.
At 5:00 in the morning today, I got in chat with a HostGator representative. An hour in, I realized that he had no idea what was going on. This happens. At this point he was confused and convinced that I was crazy as the page didn’t show a 403 error. I tried to explain it to him, but there was no point.
Later, I was able to build a small script and define a 403 page to show the representative what was going on – I also asked if he understood OpenID, which he honestly responded that he didn’t. I took time to come up with a small script to show what is going on (just a html form on a php page that shows the results of $_GET – then you could see the 403 only when you passed a url).
Here are a few things that you should really do to prep for working with OpenID:
Setup all your error pages
Understand the security limitations you might be working with on your host
Test
Test again
Check in to make sure things are working later
Understand the flow of OpenID enough to where you can explain it to people
This entry was written by Kyle, posted on April 20, 2012 at 1:05 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
Despite having produced a few projects that get the job done in Javascript, I’m never surprised when I find a quirk of the language. I am, however, surprised how it manifests in my code.
So, I am getting coordinates off of a multidimensional array. The coordinates are stored in an object something like this:
var newCoords = {'left':1,'bottom':4};
var oldCoords = {'left':1,'bottom':4};
Now, I’m trying to compare these two sets of coordinates I try
console.log((newCoords === oldCoords)); //I think this should return true
It returns false. Okay, so how about:
console.log((newCoords == oldCoords)); //I think this should return true
If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.
So, the implications of this are that you can’t even compare arrays to see if they have same values because arrays are objects. You could compare the properties of the two objects manually, but that seems like a good way to repeat yourself. I found a nice little solution for arrays, but I’ve generalized it a bit to compare arrays or objects:
function areEqualObjects(firstObj,secondObj) {
if(firstObj.length !== secondObj.length){
return false;
}
for(var i = firstObj.length - 1; i >= 0; i--){
if(firstObj[i] !== secondObj[i]){
return false;
}
}
return true;
}
It isn’t exactly elegant but it gets the job done.
This entry was written by Kyle, posted on March 30, 2012 at 11:10 am, filed under javascript. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
One theme of this blog has been to force my own hand to release work. In the past I’ve let stuff languish on my own little web server until I deemed it was perfect. And we all know how many perfect things exist.
I can’t say that I’ve been in a releasing cycle as-of-late, however I have been in an updating/refining cycle. I’ve updated both letter pile and m.easur.es to have pretty decent Internet Explorer functionality. They don’t look quite as nice as they do in a real browser, but it does open up a bigger user base.
In the past I’ve always dreaded this phase but Modernizr and JS Lint have reduced the pain. Modernizr eases the layout woes and JS Lint has really improved my code consistency and quality. IE seems to appreciate better JS.
On a side note, I’ve been traveling a lot on the weekends, I haven’t been letting this eat too much into my coding time, however. Train rides with wifi and some down time at the in-laws have been good to me and I may have some new stuff to show very soon.
I’ve been busy updating Letter Pile recently and I need to share with you a sense of guilt I’ve been feeling. It is the guilt of not making a very semantic web application. I’ve got a serious case of divitis. But this has got me thinking - in the scope of a web application or game (v.s., say, a traditional information-based web page), is it really possible to have semantic markup? Is it even useful?
Follow me for a minute – semantics are important for a few reasons:
making your site machine readable (SEO and indexable),
accessibility (adding meaning for those who use a screen reader),
maintainability (independence from visual elements for redesigns),
code readability.
In a web application, you are not just passively providing information to a site visitor, but rather you are interacting with the visitor waiting for input and providing something based on that input. As smart as the googlebot may be, it isn’t going to play your game or login to your site. Chances are, most of the information provided won’t be something that will be indexable without user input.
Having worked with accessibility concerns in my other career, I understand how many barriers exist for those with disabilities. When working with the web we (for better or worse) are often translating “accessibility” to “Will it work with a screen reader?” While great strides have been made in enabling dynamic content for those using screen readers, sometimes it is just not realistic to be able to target those with disabilities. Just as a person with a visual disability probably shouldn’t play darts or whack-a-mole, the game play mechanic of Letter Pile is very tied to response time and visual cues. Trying to target assistive technology would be a little useless, in this case.
In an ideal world, you could just swap a style sheet out in a semantically marked document and have nothing that visually ruins your page. In an application, this could be more challenging. Application development tends to be more about the user experience and, thus, closely tied to visuals. Smartly classed applications could step in to achieve the same thing, as semantic markup ,really.
Code readability is a big issue with divitis. You could go the route of making your own tags to clear up ambiguities – in the Letter Pile example, you could make elements that are something like <lettertile></lettertile> but if you are manipulating it mostly with javascript, then what is the use really? The kicker for me is really those pesky closing tags – even with careful tab hygiene, it can be a bear to look at the last 14 lines of document and see only closing div tags.
So, I’m divided. Semantics are an excellent idea but they only seem to match a limited scope of what kind of interactions can occur in the web browser. Not to mention what happens when you deploy an HTML5 app in something like phonegap – that will never been seen by a search engine. HTML5 apps are going to be here to stay, but the idea of the marking being anything but function of the visual representation of the interface may be the place that designers of web pages and web apps diverge.
Another project out-the-door – m.easur.es. M.easur.es is a little web app that parses a recipe for the measurements of ingredients and makes it easy to manipulate these measurements into different units. Sure, there are lots of online conversion tools, or even google, but what sets this apart is that it does it all with one click, instead of doing each ingredient separately, just copy the whole recipe into the box and hit “convert.”
The idea has been kicking around in my head for years – I do a fair amount of cooking and sometimes I’m baffled by how these recipes are written. Tablespoons, 1/4 cup, 1/2 cup, Teaspoons - it is too much to clean up and keep track of. In my grad school days, I started to think of recipes in parts – one part milk, two parts flour, etc. after I end up with a sink full of measuring spoons, cups and scoops. Why not try to minimize it by using as few measuring things as possible? Fast-forward a few years and I married my Canadian wife and I realized that a cup in her cookbooks were actually different than cups in mine. It is really crazy. Both of these problems were itching to be solved.
This project has been hanging over my head for quite a while now. It is funny how at the point I conceived this idea, I wanted something ‘simple and easy to release’ and I think I officially began the project on Oct 26th, 2011. At first it went quickly – I can say that most of the functionality was complete in November of last year but it was set on the back burner more than a few times. Initially, the code was a mess, but I rewrote a lot of it to make it easy to extend later on.
Feature creep also played a role – as mentioned previously I added a lot of features to this that are maybe not core to the user experience. It uses OpenID and the application cache together to allow for purchase of additional measurement packs even offline. The core of the system is regular expressions that identify the different measures. I also had to get my hands dirty with fractions and fraction conversion- something that I haven’t really done since grade school.
You can go directly to the site, but be warned, it uses extensive HTML5 and CSS3 stuff. It is a bit of a mess in Internet Explorer. I built it for the Chrome Store, so grab it and enjoy!
As evidenced by my work with jo HTML5, I’m interested in how I can apply my web development skills to the mobile arena. The other day I watched an interesting video by Stephen Woods of flickr about designing for mobile.
A few highlights from his talk – he drives home the importance of giving users feedback to their actions and he also touches on how one the biggest challenges using web technologies on mobile is the differing devices and how underpowered they can be.
Personally, I use a iPhone 4s and a Touchpad as my everyday devices. The iPhone certainly wouldn’t be considered low-end on the power scale and even the Touchpad is middle-of-the-road. As I start developing for mobile, I realized that people carry around old and/or underpowered devices too. I’ve also been thinking about leveraging the cross-platform advantages of HTML5/Javascript/CSS development and developing for Android as well as iOS. So, I purposely picked up an underpowered, out-of-date Android device (also, I’m a little cheap) – an Archos 32.
I was a bit worried that it would be too low-end to be useful. I’m happy to report that it is a relatively capable device for its pitiful specs. The worst thing is the screen size and the less-than-response resistive touch screen. I’ve been able to test letter pile and some of my other in-progress projects successfully, aside from the far-too-small touch areas. Nothing that a little reconfiguration for mobile couldn’t fix. And if it can run on an Archos 32, it can run on anything!
This entry was written by Kyle, posted on February 25, 2012 at 7:22 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
A few months ago I had an idea for a web app right after reading an article about how the application cache rocked. Always willing to try something out and learn something new, I decided that I’d give it a whirl with this new project.
The application cache is something that amazes people. I showed the web app to my wife then pointed to the my wifi indicator and asked her to go to google.com to prove that, indeed, I wasn’t connected to anything. She was bewildered. I tried explaining it to her but the intricacies didn’t seem to sink in or interest her. She did like that it just worked. It is a great concept and it moves browser-based applications forward.
As I started to flesh out the application, I needed to integrate a few other things – OpenID (through php with LightOpenID) and Google In-App Payments for Web. As I started this process things started to unravel. My simple web app started to get more and more complex. The manifest file was becoming my enemy – I had already implemented application caching and with both OpenID and Google IAP, I really needed to develop on a server, causing a few more headaches.
I’m putting finishing touches on this application right now but it has become a bit of a nightmare to debug. Here is what I’ve learned:
The manifest file really needs to be specifically listed in the network section of the file itself. That took forever to figure out.
The way I read the spec, it seemed that caching would only occur for those file specifically listed in the manifest file. In practice, it seems to cache everything that isn’t in the network section.
The debugging tools for the application cache are very crude. I’d love the ability to control the cache files from Chrome’s developer tools.
The double refresh is a bit of a pain when debugging. So, after I make changes to a source file I need to: save it locally, upload it, hit refresh on the browser, wait for the app cache to download the app to notify me that a new version is available then finally see my changes. Click, click, click, and click. It gets old.
Conceptually, I had to switch my thinking from “a dash of php in with a javascript app” to “php here, javascript here” – clear file delineation is a must.
You still get a waterfall load effect even though things are local.
So, would I do it again? Maybe. Learning it along the way has been a challenge. I know how to code for the application cache now so I will avoid the learn-through-failure process. Was it a must for this particular application? No. Could I have gotten this application out weeks (maybe months earlier? Yes.
Sorry I’ve been absent for a bit. I’ve actually been pretty busy and productive the last month or so – both with ‘real life’ things and with projects. My Jo projects have been sit a bit on the back burner for a few weeks, although I have a few posts sitting in the draft folder. Ah, the draft folder. That is at the root of my latest revelation.
See, I’ve discovered that, between my money-making (non-tech related) job , my wife, and just being a human, I have about 2 hours to code per day. That’s it. I think that I have about 6 hours worth of ideas, but only two hours to code. I feel like I have a decent skill set, but given that amount of time, my actual production output is limited. I start a lot of projects. Finishing them, well, that is where I’ve struggled. I think this video sums up some of what I’ve been going through:
In short, I need to be better at my actual output. Less grand projects, but still, high quality. Projects that get my work into people’s had. I don’t want to be the person that stares at a web app and says ‘I could have done that…’ I want to be the person that actually does it.
I’m trying to produce more – my mission statement is to “make stuff people use” and I haven’t been doing that too well. That’s going to change. Pick my projects carefully. Avoid feature creep. Release more. Promote my work. Actually, that brings me to my final topic for this post.
I’m glad to say that I’ve released my first web app for the Chrome store – Letter Pile. It is a little game written with javascript, jquery (my first real use), and HTML5. I hope you get a chance to check it out. It isn’t prefect but it is something and it works. I should say that it works for Chrome. I need to make a few adjustments for it to work in Firefox and alot for it to work in IE. But I’m not going to let that consume me.
It is out and people can start using it and that is my mission. Not for it to sit in my 80% done file.
This entry was written by Kyle, posted on February 10, 2012 at 7:27 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink and follow any comments with the RSS feed for this post.
