Fixing PHP’s ‘Warning: simplexml_load_file(): I/O warning : failed to load external entity’

Today I had to re-visit a Drupal module I wrote in 2015. The module parses an external XML file which it loads using simplexml_load_file. When I opened the version of the site that lives in my local server, and visited the page that uses the module, I got the error in the title of this entry. I checked php.ini to make sure allow_url_fopen was On. It was.

Searching the web I came to a bug report in the php website. It was suggested to restart the apache server since the contents of resolv.conf may have changed after the server, and php got their DNS servers entry. This made sense to me, since I have switched networks since turning the computer on. I gave it a try, and it worked:

service httpd restart

Other info:

  • The location of php.ini in my case, running Fedora with php installed using dnf, is /var/php.ini
  • The location of resolv.conf is /etc/resolv.conf

The sources I visited:

The unset($args[0]) PHP Pattern

Suppose you are working on a system, and want to allow users to use so-called hooks to hook into the system and change it’s behavior. Think of it as wordpress’ filter/action kind-of-thing. This is in a way, something similar to events in javascript, and the purpose is basically the same: you want to do, or let others do something when something else happens, and potentially change the way the system works, or extend its functionality.

Implementing this kind of feature is surprisingly simple. All you need is a way to let people subscribe to your hooks, and a way to call all subscribed members for a certain hook at some point. The implementation details are not really our concern right now, but what happens when you call each subscribed member.

In order for hooks to be useful, you need to be able to pass relevant information to the subscribed members at call time. For example, in Javascript, native events get passed an event object that contains all sorts of useful information. The way you pass this information to the subscribed members will depend on your implementation of the subscribe method you use.

One pattern I’ve noticed working with drupal is unset($args[0]).

Drupal uses a hook system that allows developers to hook into the system simply by following some function naming conventions. The drupal specifics are not important right now. What is important is the way drupal calls its hooks: it uses a function called module_invoke_all.

The module_invoke_all function, in its definition, takes a single argument: the name of the hook. We already mentioned the importance that being able to pass information to the subscribed member has, so why is it that the drupal function to invoke hooks takes only the name of the hook as argument? How do you pass the relevant information?

PHP, just like other programming languages allows you to pass more arguments to a function that its formal parameters. The way you access the extra arguments passed to the function varies depending on the language. In php all arguments passed to a function are kept in the $args array.

Lets say you call module_invoke_all as follows:

module_invoke_all(‘my_hook’, ‘something cool’, ‘something interesting’);

Inside the function, the $args array will have 3 members, one for each argument passed to it. So, if you want to pass those values, minus the hook name to the subscribed members, all you need to do is get rid of that, and pass the resulting array to the subscribed members. That is why unset($args[0]) does.

I’m not sure this is the best way to do it, but it is certainly interesting. If you want to read the full code for the module_invoke_all function, just check out the drupal documentation on it (!

My Take on Passwords

I’ve been wanting to write about this for quite some time now. There is a lot of effort that is put into making systems secure, and it all goes to waste when you choose a weak password. “123456789” is a weak password, “password” is a weak password, “god” is a weak password, your pet’s name is a weak password. A weak password is anything that can be easy to guess by someone that knows you well, or by a computer. A password that is only a few characters long is a weak password no matter how many symbols or strange characters you use because it can be easily guessed by a computer. Nonetheless, websites all over the web want you to choose a password that is at least N number of character or at most M number of characters; a password that contains symbols, but does not contain you name, or part of your email, or your user name, and the list goes on. This is damn stupid.

Over the years, we’ve been trained to chose really bad passwords. We’ve been lead to believe that “m00Npi3” is a strong password because it is over 4 characters long, and has weird characters. Sure, your friends may not be able to guess it, but a computer could do it rather easily. However, we go on about our lives believing that is a good password, and then we use it for everything. Websites all over the web warn us not to use the same password everywhere, but who wants to remember a hundred passwords? Sure, you can use a plugin on your browser that remembers the passwords for you, but what about when you need to access your email from the public library, or from your friend’s house? Good luck!

Yet, we’ve been lead to believe this is all for our own good.

I mentioned I’ve been wanting to write about this for a long time, but today paypal was the last load of crap that I was willing to take before hitting the keyboard. I logged into my account, and paypal kindly suggests that I should change my password. I started changing my passwords last week, so I thought “hey, perfect timing!”. I clicked the link they provided, and I was taken to a page that asked me to confirm that I was who I said I was by providing either my bank account number, my credit card number, or my debit card number. WTF? Why? I’m already in my account! But OK, lets just pretend that this actually makes any sense, because after all I could be an attacker trying to hijack someone else’s account. So I filled out my information, and I’m taken to another page that asks me for my current password, my new password, and a confirmation of my new password. I go on and enter my new password. Paypal tells me that my password is too weak because so far I’ve entered only letters, but I don’t mind, I know the juicy stuff comes in a little bit, but then, all the sudden paypal says that I’ve entered all the allowed characters, which are not many (20). WTF? Why? Why can’t I have a long password, Why?!? Paypal just made me less secure by limiting the amount of characters I can use for my password. Are they going to start charging for extra characters now? I would pay 1 cent a piece, no kidding, as long as I could get a longer password, but then that would be something really bad wouldn’t it? Imagine a company that charges you to let you choose the password you want. Wouldn’t that be something?

Anyway, I decided to leave my current password as it is. Thanks PayPal!

What is the Big Deal

Twenty characters are enough for a password, aren’t they? After all, people want to get 4-letter passwords so they don’t forget them, but that is just stupid. I can see a valid reason to set a minimum amount of characters, but why limit the maximum amount?

You may be wondering why it is such a big deal for me. Let me explain how I set my passwords.

Chosing Long-A** Passwords that You Can Remember

I start buy choosing something memorable to me, for example, I really like the movie V, so I may want to use a base for my password like:

Remember remember the fifth of november

The first problem I see is that there are spaces, and for some stupid reason a lot of websites don’t want you to use spaces in your password, so let’s fix that:


There you have it, 34 freaking characters, and this is just the base of my password. I should note that by removing the spaces I just made it harder to type it, which is a bad thing, I’ll explain why later.

Now that we have a strong base, lets add a little bit of other characters. I will use a memorable date, for example. Note that I’m just choosing a random date here in this article, but in real life I would choose a really memorable date, but that few people know, such as the date of your first kiss, if you remember that.


We are now at 44 characters, our password has uppercase letters, numbers, and non-alphanumeric characters. Now this base is easy to remember because I’m using a memorable phrase, and a memorable date, and the stragne characters are just separator. In fact, you could use them in the phrase as well:


49 characters so far. Now, lets make it unique for each site:









Good luck trying to guess those passwords, even with a computer. However, Paypal won’t let me use any of that, what a stingy website. They will only give me 20 characters. What am I supposed to do with that?

Following this recipe makes it easy to create long passwords that are easy to remember, and extremely hard to guess. Not only that, but it makes it easy to change them too. For example, if I wanted to update my twitter password, I could just add something to it, which makes it even stronger:


That is 76 characters long, and I can guarantee you that I will remember it tomorrow without having to memorize it, because it is made up of stuff that I already know. But I sure won’t remember this:


Which is a password generated by a random password generator, which by the way, says that it is “easy” to remember as:

“SIERRA INDIA golf zulu @ OSCAR HOTEL india sierra 4 ! , ECHO romeo whiskey”


But a lot of websites recommend that you use one of those random password generators.

Hard to Write, Hard to Remember; Bad Combo

I mentioned before that by not letting me use spaces, websites make passwords harder to write, and that is not good. The reason is that if my password is hard to write I will have to either write it slowly, or attempt to write it a few times. This is bad because it gives people time to see what you type. You should be able to type your long-a** password at lighting speed. I don’t care if your system doesn’t take spaces for some stupid reason, fix that on your end. Get rid of my spaces before sending my password, or even better, fix your stupid system! I should be able to use as many characters as I want, and any of them. The password needs to be easy for me to remember, but harder for people and computers to guess. However, a lot of websites force me to create passwords that are easy for computers to guess and hard for me to remember, and type.

I don’t think there is any need to mention this, but if my password is hard to remember, then I’m already in a bad situation because I will have to write it down somewhere.

Why are We Using Passwords Anyway?

Seriously, why haven’t we come up with a better way? Oh, right we have. There is Open ID, and Mozilla Persona, to mention a couple, but event those are not the perfect solution. There has to be a better way, and if we look hard enough we will find it. But we’ve settled for less. We have accepted password as the one way to do authentication, and to make it worst, we have made it hard for people to use passwords, and we have misguided them to believe that a good password should be hard for them to remember, type, and guess. That is why people think that a random number is a good password, even if it consists of only 5 digits.

There is a lot more I can write about passwords, but the ultimate thought would be that we need to get rid of them. However, as bad as it is, we have to stick to passwords for now, but I wish websites would at lease make that easy, and safe.

Finally, you should check out this comic by XKCD:

Writing HTML Right

One of the things that really bothers me in today’s web environment, is that it seems like everything has been made generic. I’ve been noticing an increasing number of websites that use class names like col-md-4 or some other meaningless class name like that one. There is nothing wrong with this, until you try to automate a task such as scrapping a website.

I’ve talked about web scrapping in the past, and I’ve also talked about how the semantic web is just a dream that we should be forgetting about. However, we shouldn’t go around giving only meaningless class names to our tags just because we don’t care much about a semantic web.

When I work on a website, I write the markup first not really caring how I’m going to display it. That is the beauty of CSS, and that is why a few years ago the CSS Zen Garden was such a big deal. When we write markup we shouldn’t care about what the element that we are describing will look like, but rather about what it is. This sounds a lot like I’m going back to web semantics, and maybe I am, but just a little bit, and not for the sake of semantics, but for the sake of separation of concerns.

The whole point of having CSS live in a different space from HTML was to keep them separate, but now we are tying them up together very tightly. This is not good.

The next time you create a website, try this:

  1. Get out your text editor, and write markup.
  2. For every tag you write, think about what it describes, and assign a class name to it that describes that. For example if the element you are writing markup for is a sidebar widget, then give it a class of widget.
  3. Do number 2 for each tag you write. If you cannot think about what a tag is doing there, it may not be needed.
  4. Use IDs. I know a lot of people nowadays say you should not use IDs in your CSS. Not using IDs in your CSS is probably a good advise, but you are writing HTML here.

You should also make sure you are using the correct tag. There are a lot of tags in HTML, and you should always make sure you are using the correct one that describes what is going on in your markup. A few years ago, a group of people decided that the web needed badly an article tag, so they added it. Personally, I think it is stupid, but I use it because it conveys more meaning that a generic div tag. The reasons why I think it is stupid that HTML 5 implements a bunch of new tags are outside the scope of this article, so I won’t go into that, but the point is that if there is something available for you to use, you should be using it.

Here is an exercise you can try:

Write a simple page using nothing but div tags. This page should be simple, but still have a variety of things like some title, a sidebar, maybe some quote from a famous person, or some contact information; just add anything you think of, but use only div tags. Once you are happy with your page, open it up in a browser and try to make sense of it. You can even take a screenshot of it.

After looking at your page for a little bit, go back, and start replacing the div tags for something more meaningful. For example, if you have a title, use and h1 tag, or if you have a a paragraph, use a p tag. Look at each div tag you wrote, and think about what it is doing, then, find the tag that better fits that description. For a list of html5 tags, you can go here: and for a list of tags organized semantically, you can go here:

Once you are done, look at your page in the browser again, and you will notice the huge difference that using the right tag does.

There is a lot more to writing HTML than this, but one thing is certain. When you write HTML you should think about content, not presentation. HTML describes what something is. After you are done, you may go back and add some classes that aid you in your CSS such as classes for columns, or font awesome classes, but do that only once you’ve made sure your HTML is marked up, properly.

Fixing Error Code 32 when Using the Twitter API

Yesterday, I started working with the twitter API. It’s been a long time since I did anything with it, and now that it uses Oauth, I found that it is a bit less intuitive, but after a couple of times you get used to validating requests, and to the tedious signing process. However, I noticed that some of my requests were failing with an error code of 32. This is the actual message I got as response:

{“errors”:[{“message”:”Could not authenticate you”,”code”:32}]}

This message is really useless considering there are many reasons why your authentication could be failing. By looking at that error message all you know is that you could not be authenticated, but you don’t know why. The reasons, as it turns out, are not as intuitive as you may think.

When someone tells you that you could not be authenticated, your first thought is to consider whether you have the right credentials. But once you’ve verified that you do, what other options do you have? Well, it could be that the signature is incorrect because you did not order the parameters in the right order. It could also be that your server is using a different timezone. Who would ever think of these as reasons for failing authentication? That is where the message becomes useless.

However, these two instances are pretty much the main reason for failed authentications, so a search will most likely give you a variation of any of these two possible reasons. However, what do you do after you are certain that none of them are the reason? You are pretty much out of luck.

One of the first things I do if something is not going according to plan, is to check that the signature being generated is the same one that twitter generates when using their Oauth Tool. For this you need to know how to modify the timestamp, and the nonce in whatever framework you are using. In mi case, I’m just doing everything by hand, so editing those values is a matter of editing a couple variables. If the signature, the Authorization string, and the signature string coincide with the ones generated by twitter, there should be no reason why your request should fail. However, despite of all 3 matching, my requests were being failed over and over.

The first thing that I noticed that made little sense was that some request were successful, while other were not. This made no sense. Why would twitter fail to authenticate one request, but not another one when both use the same credentials. This is yet another instance of that message being totally useless.

I decided to go over my requests and find out what was different. I noticed that the request that failed were the ones where data was being posted. I was using php’s curl to do the requests, so I decided to go and take a look at the documentation just to make sure I was doing everything right.

I discovered that PHP can take POST parameter in two ways when using curl. The first one is a string of key value pairs separated by ampersands:


The second one is using an array:

array (
  'key1' => 'val1',
  'key2' => 'val2'

Well, it turns out that if you use an array, php will set the Content-Type header to multipart/form-data, but then twitter will fail to authenticate you. Although the reason for failing the request may be an acceptable one, the message you get back is not, because it gives you no indication whatsoever as to why the request failed.

Next time you encounter that error code 32, remember to check you headers as well as your data, along with the server timezone, the order of your parameters when building the signature string, and you may as well check that you are not wearing anti-twitter outfit, just to be sure twitter will not deny your request because of that too.

Iterating over an HTMLCollection

I have always expressed my lack of interest in jQuery. I don’t like it as a framework, but I like even less the fact that it contributed to the creation of a wave of bloated websites. There are countless of sites that load jQuery just to do a transition, or to hide an object.

jQuery also contributed to the proliferation of plugins that don’t really do anything other than providing eye candy, but don’t improve the overall usability of a site, sometimes they even worsen it. jQuery also created a culture of instantaneous code, where people think everything is as easy as doing $().

Despite all its faults, jQuery did great things. It hid away the complexities of dealing with the DOM, it helped many people enter the world of Javascript, and it demonstrated that there are better ways to do things.

One of the things I like about jQuery is the fact that you can almost effortlessly apply changes to a collection of elements. Think for example, that you had to move all elements that had a certain class name to the left by 10px. Now, lets say you must do it with javascript. With jQuery you would do something like:

$('.className').css('left', '10px');

Compare that to the amount of code you have to use to do the same thing with vanilla js:

var nodes = document.querySelectorAll('.className');
for (var i = 0; nodes[i]; i++) {
  nodes[i].style.left = "10px";

That is not too bad, but it is not as simple as the online jQuery code. The for loop is just boilerplate code. There is a better way to do it:

function iterateCollection (collection) {
  return function(f) {
    for(var i = 0; collection[i]; i++) {
      f(collection[i], i);

This is a nice little function that will allow you to iterate over a collection of nodes, or an array even, and then it will call a function passing it the current index, and the element at that index. To call it, you simple do this:

iterateCollection(nodes)(function(node, i) { = "10px";

While it may not be as little as the jQuery code, it eliminates the need for the library. Also, the function can be used with other functions to create more interesting patters.

I am currently working on a DOM library that takes advantage of this kind of patter as an implementation of functional programming for DOM manipulation.

Fix it Wrong: the Hyperlink Shortcomings

Catching up with my reading, and trying to free my browser of all those tabs open, I came across an article that covers an interesting problem, and offers a weird solution. This article introduces Sparkicons.

Sparkicons are a proposed solution to a real problem. How many times have you clicked something just to be disappointed with where the link takes you? I have been a victim of this a few times. Some time ago, I was using my tablet, and clicked on the download button of the Aviator Browser home page. I am so used to download buttons taking me to a page where the actual download button exists. For example, the site has a download button that when you click it, it takes you to another page where there is another download button. I don’t download many things from the web, and maybe that is why I have a this wrong idea in my head. But the sites where I download things from make use of this bad pattern that I now think any download button in a homepage is just a link to the download page where the actual download button is.

On Bad Patterns, and Worst Practices

This problem that I have highlights the effects of using bad patterns in Interaction Design. If the people deciding what happens when I click something decided to layout the correct behavior this problem would not exist, and I chose to believe I’m not the only one who has it. This problem extends far beyond download buttons. There is, for example, the issue where many popular download sites have too many download buttons that you don’t know which one is the real one, and which one will just download some virus or scam. This is bad interaction, and UX design, but there are also bad practices that are used in the name of SEO.

In my opinion SEO is one of the worst things that has happened to the web. Sites should be indexed by their importance, not by their clever usage of technology and language. However, sites like google encourage abusive practices. One time I sent a criticism to a popular site regarding their poor chose of wording when creating hyperlinks, even when better words where in the text. For example, they would have something like this:

This article presents the advantages of using modern tools.

and they would put the link on “This article”, and not on “the advantages of using modern tools”. The second set of words is obviously a better choice, but when I pointed this out, I got a response saying that they know that, but they used the first set of words because of SEO. I lost a lot of respect for the site, the editors, and anybody involved in that decision. I decided that if they cared more about SEO than about being explicit to their readers, and using best practices in favor of their readers, I did not want anything to do with them.

Taking Responsibility

Anybody who creates content needs to be responsible for that content. Creating high-quality content should be our ultimate goal. I don’t see any need to do anything more than what wikipedia, and the BBC are doing (reffer to the article about sparkicons linked at the beginning). There is no need to add anything else because the text of the link should be always explicit. I cannot imagine a situation where being explicit is not possible. It is the content creator’s responsibility to make sure that the created content is clear, explicit, and easy to understand. This is what wikipedia, and the BBC are doing. There is no need for any sparkicon, which by the way is just the same idea, but on steroids.

I Think you Need a Button

Another big problem is that we want links to do too much. We use links to link documents together, to download things, to put things in full screen, to create new content, to delete content, to show and hide content, and maybe others that I’m forgetting right now. Links have one job: to link documents. If you need to do something different, then you need something different. For example, to go fullscreen, and to download content, you should be using buttons. We use tools wrong, and then complain that they don’t work well.

The Browser Fault

One thing I don’t understand is why in the world mobile browsers just donwload things. I like desktop browsers, because when you click a download button, they ask you if you want to download the thing, and where you want to put it. This is great. Sometimes you clicked by accident, or the link was miss-leading, or your cat stepped on the click button, or something else happened, but you did not intend to click on that button. That is why browsers should not assume you want to click on it, and download something. This is even more true with mobile devices where you have to touch the screen, and there are many reason why you could touch it without it meaning you want to click on the button to start a download. Browsers are breaking an established flow, and creating one that does not offer any added benefits. I don’t understand this logic.

Finally, while I appreciate the effort that was put into thinking about sparkicons, I don’t think they offer any real benefit over what some websites are already doing. I honestly believe that it all comes down to the same thing I’ve been saying for a long time now, the web technologies are unfixable. We need to start anew considering the current state of things and where technology is going. It is not a matter of adding more sugar on top of a broken model, but rather about letting go of the old , broken model, and create one that suits the current state of technology and that is more future friendly.

CSS Variables, Yet Another Step in the Wrong Direction

From the first time I learned about CSS variables some time ago, I noticed it was a stupid implementation. This is what we get when the people writing the specifications are not one bit close to the real world development scene. How can a person who doesn’t write CSS on a daily basis know what the best way to implement something is. Add to that the fact that variables in CSS are completely useless by nature. However, the “developers” asked for them, and they got them.

CSS variables are still something that lives in the future. They are like an incredibly stupid monster that lives in another dimension, but that has managed to open a portal, and is now showing one of its ugly paws through it. But I’m not the type to mix science fiction with reality, and I don’t usually write in this style, so I’m going to stop now.

Going back to my usual ranting style, let me tell you why CSS variables are stupid, and dangerous. But first, lets take a look at the motivation.

I Want to Feel Like a Big Pants Geek Boy
Or Why CSS Variables

It is my belief that CSS variables come deep from the need of designers to feel like developers. I’m not trying to insult designers here. I have great respect for some of the work that great designers have done, but now that the web has given birth to the front-end wave, there are a lot of designers out there who want to feel like they can call themselves front-end engineers. This is not a good thing. Designers should be proud of being designers simply because their work is amazing. But being geek, nerd, and coder is the fashion now, so many designers want to be that too.

Today I read this on a blog post:

If there is one thing a language needs to qualify as a programming language, it’s variables; they’re incredibly useful, save us a bunch of work and typing, and improve coding all-round.

This is simply a demonstration of both, the need of some designers to feel like they can program, and their lack of knowledge of programming languages. But I’m not going to start attacking people just to make me feel better. I think I should just continue attacking CSS because after all, that is what is ultimately wrong. If we really want to make CSS better, we need to throw the current specs out the window, and start anew.

The Nightmare of CSS Variables

I wanted to have a bit of a better base for my arguments, so I decided to head to the source of the problem. I searched for the W3C specification of CSS variables. It is still an Editor’s Draft, but in this stage we can begin to see some of what is wrong with CSS variables. Take a look at this example, taken from the W3C site:

:root { var-color: blue; }
div { var-color: green; }
#alert { var-color: red; }
* { color: var(color); }

<p>I inherited blue from the root element!</p>
<div>I got green set directly on me!</div>
<div id='alert'>
  While I got red set directly on me!
  <p>I’m red too, because of inheritance!</p>

I really hope you see what is wrong there, but if you don’t, I’ll give you a hint: the paragraph element can be a different color depending on where it is, event though you specify a “specific” color for all elements. This is because of the stupid implementation of scope.

The scope of the variable is resolved in terms of the location of the element in the HTML structure. What!? This is wrong, and you can go and find as many justifications for this as you want, but it won’t change the fact that this is just wrong. It would have been better to implement namespaces rather than this kind of scope.

This behavior is defined as “cascading variables”. In a sense, it is not even a scope chain. It is a freaking cascade! Why would you want your variable values to cascade? This should be called randoms instead of variables, because the value of the variables will change almost randomly depending on where the element is in the html.

This cascading behavior introduces inconsistency. Inconsistency is enemy of robustness because it creates unexpected behavior. However, CSS variables introduce a whole lot of inconsistency and complexity to an already complex language. The bad thing about this complexity is that the complexity is not in the language itself, but in the way the language has to be written in order to be efficient. In other words, writing complex, hard-to-maintain, CSS is a requirement so much they almost advertise it as a feature.

Who Needs Variables Anyway?

I like to believe there is a better way to write CSS. I’ve been recently experimenting with what I call Subscription Based CSS. It has allowed me to create more consistent behavior, easier-to-maintain CSS, and a smaller code base. Explaining Subscription Based CSS is out of the scope of this entry, but the basic idea is to develop sets of styles, and simply add selectors to them. This eliminates completely the need for variables. Think of this example:

color: #bada55;

We have defined a color set. Now, whenever you need a certain element to have that text color, you simply add a selector to the rule set. For example, if you want all your h1 elements to have this color, you simply subscribe them:

h1 {
color: #bada55;

If you also want elements with the class “badass” to have this color, you subscribe that selector too:

h1 {
color: #bada55;

There is no need for a variable called var-badass, and there is no unexpected behavior. The .badass elements, and the h1 elements will always have the same color regarding of cascade values.

You can apply this same principle to any CSS property, and you can do more than variable can do. For example, if you want elements to have the badass background color, and white font color for nice contrast, you define that set:

h1 {
background-color: #bada55;
color: #fff;

This is a much better way to deal with constant values.

F! Semantics

In my early days, I was pro-semantics. Semantics were the hype back then, and I saw a lot of value in that. Semantics rely heavily in class names, and we learned that using class names that described the visual representation of the element was bad. This means that if you have a class like “centered_text” you are doing it wrong. Why? For the sake of semantics, of course.

Nowadays I’m not as big a fan of semantics as I used to be. Class-based semantics are a redundant task that has little added benefit for the end user. They are of great benefit for robots, and automated machines, but we do web for users, not robots. Once you forget semantics, writing subscription based css is really easy.

I don’t think CSS variables will go away. They are just another feature in the web that takes us a bit further from where we should be, and that diverges us a bit more from the direction we should be following, but like everything else, it is up to the developer to use the feature or not. I’m sure they will be loved by many because we tend to see any new feature like a new toy we must use as much as possible. I think we will start seeing CSS frameworks that claim to be the perfect solution for CSS variables, just like it happened with grids. With that in mind, I can safely say that I saw the future, and it was awful.

grumpy cat

CSS Hover Intents

Hover intents were the fuzz word for a little while some time ago. The basic idea is that you should not fire a hover event handler as soon as the event happens, because the user may not actually intent to hover over the element, but he might just be rolling the mouse over in order to get somewhere else.

The javascript implementation was simple, involving some king of timer. Someone even created a hover intent jquery plugin. But to me it seems excessive to use Javascript to manage hover intents, specially now that most of our animations are handled by CSS.

A few weeks ago I was thinking about implementing hover intents in CSS. I’m not sure if anybody has come with this patter before, but I had never seen it until I came up with it. The idea is the same as in javascript, but you can implement it in pure CSS.

The “trick” is to take advantage of the transition property of CSS elements. After all, we usually want to do hover intent on animations and transitions, like when we are sliding down a menu, or adding some hover state to an element.

The code is simple:

.selector {
transition: .5s .3s linear;

Here we are specifying a transition that should take .5 seconds to complete, but should start with a .3 seconds delay. This effectively creates the hover intent effect.

Look at this demo to see it in action:

Notice that I made the delay 1 second just to make it more obvious. This has been tested on Google Chrome and Firefox. You can even specify a different delay for the mouse enter, and mouse leave events by re-defining the transition property on the :hover rule with different values.

The Slider Problem

Browsing through the popular items in theme forest, I’ve come to realize that there is a horrible anti-patter out there. I’ve noticed this before, but I didn’t realize the full extent of it until I browsed many different templates. The anti-pattern is image sliders, or slideshows. There is actually nothing wrong with the sliders themselves, the problem comes when they have a dynamic height. What most people do is calculate the height of every slide and re-size the element accordingly. When the element is re-sized, anything that is placed bellow it in the document is pushed down, or pulled up. This is a problem.

Sometimes the slider is not even visible anymore, and you are just reading the content, and all the sudden it moves up or down making it really hard and annoying to read. This is an anti-pattern.

The solution is really simple. Pause the slider when it is obvious the user is not interested in it anymore, like when half of it is not visible anymore. If half of the slider is not visible, then it is safe to assume the user has moved onto something else, and is probably now concentrating on the content bellow the slider.

To solve this problem, I’ve created a jQuery plugin called scrollWatch. It is easy to use. You can call scrollWatch on any element passing a callback to scrollWatch. Every time the window scrolls, the callback is called and an object is passed to it. The object contains some information about the current state of the element, such as the amount of pixels hidden on each direction (top, left, right and bottom), the percentage hidden, the width and height of the element, it’s position on all 4 corners, and other window related information. For now it works only on window scroll, but it could be easily adapted to work for other elements as well.

There are many things that can bone when you have the option to know how much of an element is hidden because of scrolling at all times.

I will release the plugin through git hub at some point this week, stay tuned!