Suzanne Hillman (Outreachy): CSS and mockups

I want to get a better feel for CSS, so Máirín Duffy (Mo) and I spent three hours last week figuring out how to moving a pixel perfect mockup to CSS. This was made up almost entirely of background stuff, but we got a lot of useful information in the process. We will continue working on this sometime this week.

Git and Pagure

The first hour or so was spent fighting with git and making me a fork of a fork of the main repo.

In short, I had to:

  1. make sure my SSH key was in pagure,
  2. tell local git about the fork using “git remote add -f sayan ssh://”,
  3. grab the fork with “git checkout badge-path-support”,
  4. use the webui for pagure to tell it to create me a fork, and
  5. finally “git remote add -f wispfox ssh://” to push my fork.

There were many other complicated aspects that I will figure out later.

What are we trying to do?

She gave links to the ticket we were planning to work on (, and pointed me at the specific mockup we were going to try translating (the team badge widget):


She also pointed me at one she had already done (the individual badge widget,


Mo pointed me to the HTML that she’d done for this widget, and pointed me to where that HTML was injected into other HTML.

Exploration and Explanation

Mo explained that hubs is built with python, using a platform called flask, which uses a templating system called jinga. As a result, the templates in question are written in jinga.

The entire site is written in fragments which are then combined together appropriately to create the page. She then mentioned that in flask, each widget has a .py file, and a corresponding template in HTML, and CSS pulled from the main CSS file.

We started looking for the team badges ( file so that we could start working, and figured out that it was actually in a developer fork. Once that was done, she suggested I use the IDE geany to open the py file and the badgespath.html file. She opened an etherpad and pasted what she had in her html file into it, as she’d already started working on this task.

To see what was going on with what she’d been playing with, I saved her changes to the file, and started a local Hubs instance. I logged into it, and added the team badges widget to my profile page (since I didn’t have permissions to the design hub). This resulted in a great deal of messy-looking output, which Mo explained was JSON output. After a brief divergence to explain what that was and fight with IRC, she explained the code she’d had me paste into the file.

Because we can have multiple of the same widgets in a page, she uses “class” instead of “ID” to label each widget in CSS. Then there’s jinga logic, which is python syntax surrounded by {% %}. The badge and series_info variables were referring to things defined in the file.

She then explained the py file contents, including that import and from relate to libraries, argument says what information the widget requires from the user, def defines a function (in this case, one called data which takes in session, widget, and username as arguments). The function data had a username and team_id hardcoded for testing purposes; the team_id will be found by looking at which hub the widget is being added to in the real code, no need to ask the user for that information.

The data function is grabbing a bunch of JSON info, and splitting it into useful pieces, including badges_count and series_info. This information is then stored in a dict, returned, and available to anything requests it; in this case, our original badgespath.html file.

What Mo was trying to do in the html file was get a sense of the JSON info. So she added some debugging info (commenting out the stuff in the for loop, adding labels to badges count, series info, and badges), and we restarted the server to see what we got. We then tried taking a look at the JSON output in a JSON parser, and found out from a developer in channel that our output was in need of running through a dictionary.

After a great deal of investigation and confusion and talking to the developer who made the fork, it turned out that the JSON information we were getting was a local file because the information we needed about teams badges per user was not in the production environment.

We learned that

  • The series_info file contains information about badges that are in series’ for a particular team.

For example, a series in the infrastructure team has a badge for having a FAS account for a year, having one for two years, having one for three years, having one for five, for seven, and finally for ten.

  • “is_awarded” in the series_info data identifies the badges a particular user has in that series,
  • badges_count is the total number of series badges for that team (but it doesn’t yet tell us how many non-series badges that team has), and
  • ‘series badges’ is a set of badges that are related to Missions in the mockup.


Source From:
Original article title: Suzanne Hillman (Outreachy): CSS and mockups.
This full article can be read at: Suzanne Hillman (Outreachy): CSS and mockups.


Random Article You May Like

Leave a Reply

Your email address will not be published. Required fields are marked *