Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


CSS2 selectors

Was working with CSS2 selectors today, thought I’d write a post about that.

Consider the following HTML code:

CSS selectors come into play when you want to select specific elements. For instance, suppose I had a CSS declaration such P { color: red; } it will apply to all P elements in the HTML – which may not be what I want. What if I wanted to target only the first P element instead? Or P elements following an H2 element? That’s when you’d use a selector. Selectors make use of relationships between elements.


Every element in a given HTML code has a relationship to other elements in the code. It could be a child to another element, an adjacent sibling, the first child of an element, a grand child to an element, and so on. Below I have enumerated the elements from the HTML code above into a form that shows the elements and their relationships. Some elements have a + instead of | – this simply indicates the element is the first child of that type.

Child selectors

Child selectors are used to match elements that are children of another element. The > symbol is used to indicate a “child” relationship. Some examples:

  • LI > P { color: blue; } will target only those P elements that are children of an LI element.
  • OL > LI { color: blue; } will target only those LI elements that are children to OL elements but not UL elements.

Descendant selectors

Descendant selectors are used to match elements that are descendants of another elements. An element is a descendant of another element if it is a child of that element or if its parent is a descendant of that element (pretty obvious usage of the word, actually). A space between elements is used to indicate “descendancy”. Some examples:

  • P STRONG { color: blue; } will target only those STRONG elements that are descendant to a P element. This will not pick the STRONG element that is a child to H1 for instance.

While the child selector is for the immediate children – and does not select grand-children – the descendant selector includes children and grand-children. That’s the difference between these two operators.

Thus BODY > H1 will select all H1 elements that are a direct child of the BODY element – skipping the H1 element that is a child of DIV (hence a grand-child) – while BODY H1 will select the latter too.

If you want to select all descendants except the child – i.e. only the grand-children and further – the * symbol can be used instead of a space. Thus in the HTML code above, BODY * H1 { color: blue; } will skip the H1 elements that are children to the BODY element but target H1 elements that are children to the DIV element (as these are grand-children and descendants).

First child

Notice how I had marked many elements as the first children in my tree of HTML elements above. The reason I did that is because there’s a selector to target just the first children of an element. This is a pseudo-class actually – like how to add a :hover to match A elements when the mouse is hovering over it – so you add a :first-child to the element. Some examples:

  • P:first-child { color: blue; } will target only those P elements that are the first children of any element. In the HTML code above, this will match the P elements with the text “Hello and welcome to my page!” (first P element child of the BODY element) and “I love Batman!” (first P element child of the LI element).
  • Similarly, LI:first-child { color: blue; } will target only those LI elements that are the first children of any element.
  • It is possible to combine selectors too. BODY > P:first-child { color: red; } targets the first child from all the P element children of the BODY element while LI P:first-child { color: red; } targets the first child from all the P elements descendants of the LI element.

Adjacent sibling selectors

Adjacent sibling selectors are used to target siblings that are adjacent to each other. Two elements are siblings if they have the same parent (again, an obvious use of the word). Further, for this element to target such siblings, they must be adjacent to each other. Bear in mind the target is the second sibling, not the first. Some examples:

  • P + P { color: red; } will target all adjacent sibling P elements.
  • P:first-child + P { color: red; } will target all adjacent sibling P elements only if the first sibling is also the first-child. In the HTML code above only the “Here are some of the Batman villains” line matches this criteria.
  • LI:first-child + LI { color: red; } will target the second LI element of every first list.

See also

These are the main selectors. There are some more selectors – based on attributes of the elements and/ or language – best to refer to the W3 CSS2 selectors page for that.

Create and delete remote git branches

Creating and delete local git branches is easy:

Once you have created a local branch, you can push it to the remote. Note: the branch must exist locally.

  • OPTION 1: switch to the branch locally, and then push

  • OPTION 2: stay on the current branch, and when pushing specify the local branch you want to push

    Notice the syntax: you specific the remote repository name origin and then specify the local branch name, colon, the remote branch name. The remote branch can have a different name from the local branch too.

    The proper syntax of the git push command can be seen in option 2; while option 1 is the simplified special case version. The [local branch name]:[remote branch name] part is known as a refspec.

Which brings us to delete remote branches. To delete remote branches, you do the same as above except that you push an empty local branch to the remote branch that you want to delete – effectively nullifying the remote branch! It’s non-intuitive in a way, but I find it very geeky and logical. It’s as though you no longer had a delete command on your file system, and if you wanted to deleted a file you copied /dev/null to it thus deleting it.

Git branch verbose

This is worth remembering:

These switches work with the -a switch too:

Don’t forget: this is cached information.

Git pull default

The same way you can set the default repository and branch to push to, you can set defaults for git pull too.

The master branch has a default set automatically when you clone the repository the first time, but branches don’t have these unless you specify manually. We’ve already seen the command to specify upstream branches manually when pushing. The same command applies here too:

Here testing is the local branch and origin/<branch> is the remote branch. I can skip testing if I am already checked out to that branch locally. And I can skip the = sign between the switch and remote name. Also, -u can be used as a shorter alternative to --set-upstream-to.

Here’s what the command actually does:

Git push default – difference between simple, matching, current, etc.

Whenever I’d issue a git push without specifying the remote repository or branch, expecting it to just pick up the default remote repository and push to the remote branch with the same name as the current local branch, I get the following message:

Usually I’d ignore the message and go ahead anyways, but today I decided to explore further.

So, first up: what are these two behavior options matching and simple? From the git-config manpage I understand there are five such options:

  • nothing: If you don’t specify the remote, do nothing.
  • current: If you don’t specify the remote, push the current branch to a branch with the same name on the remote end. If a branch of the same name doesn’t exist at the remote end, create one.
  • upstream: If you don’t specify the remote, push the current branch to the branch you have designated as upstream. Note: this is similar to current just that the remote branch isn’t chosen based on one with the same name, it is chosen based on what you have set as the upstream branch. This is useful when the remote branch name is not the same as the local branch name.

    How do you set a branch as upstream? Use git branch --set-upstream-to. (Note: --set-upstream too works but is deprecated. You may also use -u instead of --set-upstream-to).

    Here’s an example. I have three branches for my repository: 0.1, master, and testing. All three branches exist both locally and remotely.

    Next I change the push policy to upstream and …

    The last example makes the difference between current and upstream very clear. If the push policy is set to current it always pushes to a branch of the same name on the remote end, and if such a branch doesn’t exist it creates one. This makes it impossible to have your local branch point to a differently named remote branch and issue git push without any further instructions and expect it to work. If that’s the behavior you want, be sure to set the push policy as upstream.

    As an aside: I found this and this – two useful posts from StackOverflow to understand the concept of an upstream remote. These in turn helped me understand why the push policy is called upstream and the scenarios where one might require such a policy. This GitHub help page too is worth a read.

  • simple: If you don’t specify the remote, push the current branch to a branch with the same name on the remote end. However, if a branch of the same name doesn’t exist at the remote end, a new one won’t be created. Thus simple is a cross between current and upstream – unlike current it does not create a new branch and unlike upstream it cannot push to a branch with a different name.

    Starting from Git 2.0 the simple will be the default for git push. This is the safest option and so considered beginner friendly.

  • matching: If you don’t specify the remote, push all branches having the same name on both ends.

    If a branch of the same name doesn’t exist at the remote end, create one.

    Currently matching is the default git push policy but starting with Git 2.0 it will be replaced with simple.

Good stuff! I’ve now set my default to simple.

Useful Sublime Text 2 stuff

Sublime Text 2 has packages – basically modules made by users that extend Sublime’s functionality.

Package Control is your friend when it comes to finding & installing such packages. Installation instructions are on the site. Once you install it and restart Sublime go to Preferences > Package Control and select Install Package to search for a package and install it.

A great feature of Sublime is that of viewing the same file in multiple panes. So I can open a file, view it in two panes side by side, and any edits I make in one pane will automatically reflect in the other. This is very useful when you have code all over the place in a large file. Without panes you’ll have to keep moving around, but with panes you can stay where you are in one pane and use the other pane to move to where you want to be.

To create a new view of a file go to File > New View into File. This will open a tab with the same file. Next, go to View > Layout and choose a layout (I prefer Columns:2). This will split the Sublime window into two columns. Then all you have to do is drag the tab with the new view into the newly created column, and you’ll have both views side by side! Nice.

Here are the packages I installed (will be updating this list as I add more):

  • Find Function Definition: Let’s me select a function name in my code and press F8 to find the function definition. I expected the package to search the currently open file(s) and find the function definition, but it does not work that way. You have to define a Project first as only files in current project are searched. I have all my code as various sub-folders of a folder anyway, so I just created a new Project by going to Project > Add Folder to Project and added this folder to the Project. Then I went to Project > Save Project As... and saved the Project so I can easily open it in future. I haven’t explored Projects much, but it seems to be a way of clubbing together multiple folders to create a project and defining common settings just for that project. When you save the Project two files are created, and this is the impression I got from looking at those files.
  • Origami: Makes the aforementioned task of creating new views etc very easy. Creates a menu under View > Origami (and defines keyboard shortcuts) to create new panes, clone the open file into the new pane, etc.

Good stuff!

Console2 and Sublime Text 2

Had read about Console2 (a command prompt application) and Sublime Text 2 (a code editor) on many blogs and decided to give them a try today.

Sublime Text 2 is straight-forward. (1) Download from here and install, (2) navigate to the folder where you installed it and then the Data\Packages folder within that, (3) create a folder called PowerShell there, (4) download this GitHub repostiry as a zip file, and (5) unzip it into the PowerShell folder previously created. Steps 2-5 are for adding PowerShell syntax highlighting to Sublime Text.

That’s just scratching the surface though. I’ve still got to explore why Sublime Text is so cool. It looks great if nothing else; I like the colors and fonts and just how it looks over all.

Console2 is also straight-forward. Download, install, and launch. Then go to Edit > Settings to tweak things. Here’s what I changed:

  • Under the Console section I set the Shell to PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) and the Startup directory to my folder containing code.
  • Under the same section I set the Window size to be 38×163. Arrived at this number by resizing the window with my mouse (the size appears in the bottom right corner of the status bar). That’s a cool thing about Console2 – you can resize it with the mouse!
  • Under the Appearance section I unticked Show command, Show command in tabs, and Tab titles. Ticked Use console window title. Set the font to Consolas size 12, with ClearType smoothing. Also I set the initial position to 45×58. Arrived at this number through trial and error for my screen.
  • Under the Appearance | More ... section I un-ticked Show menu/ toolbar/ status bar and also Tray icon. Set the Window transparency Alpha for both windows to 10. Number arrived at through trial and error.
  • Under the Behavior section I ticked Copy on select. This will give me the default PowerShell behavior which is to copy text to the clipboard when I select it. The cool thing is now it will work for the regular Command Prompt too!
  • Under the Hotkeys section I changed Copy selection to be Ctrl+X and Paste selection to be Ctrl+V. I really didn’t need to change the hotkey for Copy as just selecting text will copy it now thanks to the setting in the Behavior section. But it’s convenient to be able to Ctrl+V for paste. I didn’t set Ctrl+C as the hotkey for Copy as that would stop me from being able to interrupt commands via Ctrl+C.
  • Under the HotKeys | Mouse section I cleared the entry for Copy/ clear selection and assigned Left (without any modifiers) to Select text. This way I can just left click and select text with the mouse (and it will be automatically copied to the clipboard anyways thanks to the setting in the Behavior section). I assigned Right (without any modifiers) to Paste text, and Right with the Ctrl modifier to the Context menu. (Update: I have since changed my mind and assigned Paste as Right with Ctrl modifier (the default) and Context menu as Right (without any modifier) (the default). That way I don’t accidentally paste text by right clicking anywhere in the window).
  • Lastly, under the Tabs section I made removed the existing entry and made two. One called POSH, with C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe as the Shell and my code folder as the Startup dir (could skip the latter I guess as it’s set as the default earlier). And another called CMD, with C:\Windows\System32\cmd.exe as the Shell and my code folder as the Startup dir. For both these entries I set the Icon field too. You can only supply ICO files as icons, so I used IconsExtract to extract the icons from the PowerShell and command prompt executables and saved them as ICO files.

And that’s it.

A cool thing about Console2 is that the two tabs I defined above are just “types” of tabs.

Here I defined one tab of type PowerShell, another of type Command Prompt. I could create other types too – for say, the BASH shell, a script based menu, an SSH session (not PuTTY though, that opens a new window and crashes Console2) and so on. I can make up to 10 such tabs – or at least I can assign shortcuts for up to 10 such tabs – so using the default shortcuts I can press Ctrl+F1 and in my case that will create a new tab with PowerShell loaded. I can cycle through these tabs with Ctrl+Tab and Ctrl+Shift+Tab as usual and close these with Ctrl+W too. All hotkeys can be changed too. Neat!

Update: Console2 stores its configuration in a file called console.xml in the same folder as the program. I have uploaded my copy of this file, along with the two icons, here.

List remote Git branches

I used to think git branch -r was the way to go for finding remote branches.

Until today, when I was working on repository I hadn’t updated locally for a while and doing git branch -r gave me some older branch names that I was pretty sure I had deleted (and double checking GitHub confirmed that too).

Moreover shouldn’t git branch -r prompt for my SSH key when connecting to the repository? It doesn’t, so maybe the command’s just returning some cached info?

Turns out the accurate way of querying a remote repository is to use the git ls-remote command:

This does show the correct branches.

A better way to do this is to use the git remote command. This is easier to remember too and the output is more informative:

This command actually runs the git ls-remote command behind the scenes. If you want to see the cached information instead (what git branch -r was looking at) use the -n switch:

To remove the branches that are no longer present locally (stale branches) use the git remote prune command:

To summarize:

  • View current remote branches via git remote show origin
  • Prune stale local branches via git remote prune origin

Of course replace origin appropriately if your remote has a different name. The primary remote repository is usually given a friendly name origin.