In the past week, I took a stab at trying out the Twitter Bootstrap that I marveled at last week. I was excited to try out the tons of great features and components that it promised, but I was also prepared to struggle a little due to the fact that I was going to be transform an entire page (not to mention an entire site!). Nevertheless, I was happy to try it out, and as it turns out, I did in fact meet both satisfying success and disappointing difficulties.
First off, as expected, it was extremely easy to implement some of the basic layout components by using the handy classes; I just tacked on a few classes, and like magic, the site transformed itself instantly with no trouble at all. Of course this was just for the basic classes like "container" and "fluid-row", and there are more advanced tools to use, what with the fluid grid system that will take some thought and trial-and-error to perfect, but that will be one of the steps from here on. At least for the simple pages, I don't foresee much more complex implementation being used than just these basic containers. However, responsiveness is a key part to our site, and getting this to work was what gave me some grief this past week. According to the Twitter Bootstrap documentation, adding responsiveness can be as easy as adding classes to the containers that are desired to be made responsive. These classes are: "visible-phone", "visible-tablet", "visible-desktop", "hidden-phone", "hidden-tablet", and "hidden-desktop", which as one can probably guess, makes the container visible or hidden according to the size of the browser. I eagerly added these classes to my page, but to my dismay I saw no change in the responsiveness of the page. Thinking that I must've missed something, I searched around and tried to get it to work, but to no avail. The closest that I got so far was getting "hidden-desktop" to work by importing a "responsive.less" file that I had to obtain through GitHub (it wasn't contained in the zip file available for downloading). So I got a phone feature to hide when the browser was large, but strangely enough, it wouldn't pop up like I thought it would when it got to a smaller size. At this point, I didn't have much time to fiddle with it very much, so as it stands, responsiveness is very limited. Either I must figure out how to get this to work, or I will have to end up implementing it the old-fashioned way-- by hand using media queries, but that would ruin the spirit of using a framework. Sigh.
As for LESS, I was met with less stubborn parts, but as anticipated, it did take some time to get used to coding in the style of a programming language. As a result, I did not get to finish restructuring the theme CSS file to fit the LESS style, but nonetheless I was able to cross several basic components into LESS, such as the use of variables and nesting rules. There is not much that is difficult with this, except for making sure that the changes don't mess up the styles. This means that changes need to be done carefully, especially where we have previously used chained rules (using the comma to specify multiple containers). Therefore, it might be better to take out all unnecessary components and slowly add them in according to each page, because we want to write less CSS. I will probably end up following this approach, and hopefully I will come up with a working, simple, and concise page very soon.
No comments:
Post a Comment