---
tags: mstu5003, tinker, html, css
---
# Tinker: HTML/CSS - Meow Mix :smile_cat:
> **Group Members:** Michelle Avenant, Zexin Lyu, Congyu Zhang, Pranisa Thongbhakdee (Pam), Peixuan Ren
See demonstration: https://codepen.io/jmk2142/pen/dVMRRq
**TINKER** - _attempt to repair or improve something in a casual or desultory way, often to no useful effect._
It's funny that the problem is called a "tinker" problem in that tinkering is usually messing around with stuff without a very planned way. I think, when we use the word tinker, it's really to emphasize the _spirit_ of the activity; that is to not feel too pressured into treating it like a test of your ability. It's really meant to be an opportunity for you to explore and have fun messing with stuff while using the guided questions to challenge your understanding.
So in some ways - while the spirit is about tinkering - I actually do want you to explore this in a directed way. That is:
1. Manipulate things to understand the causal effect and relationships it has on the results.
2. Think about the multiple manipulations you make to generalize certain key patterns that manifest across different episodes.
3. To generate hypotheses about how stuff works, and to test those hypotheses (through manipulation) to confirm or reject your ideas and refine.
As such, for each tinker problem which will be a "full" example - I will be providing you with certain guiding questions to help you direct your attention and activities to the _hidden_ things that are present. Think about it as if you just discovered a strange and fascinating new bug crawling across your table. You just want to poke it to see what it does. And I encourage you to do so.
## Tinker Tasks
As a general flow:
- First, take the base codepen and **fork** it.
- This will branch the original code so you have your own copy that you can edit and manipulate.
- Next, **compare** what you see in the code and **map** the relationships between the code and output.
- Then, use the guiding prompts and questions to **manipulate** the actual code **one thing at a time** and _see_ what happens.
- Be able to **articulate** your understanding and share your findings and insights with your weekly group and/or the class.
Note that I use Markdown as the format for these things as it is pretty `programming friendly`. You can get a basic understanding of Markdown in a few minutes using the following interactive tutorial: http://www.markdowntutorial.com
---
## Tinker GUIDES and QUESTIONS
> Here is our codepen: https://codepen.io/msa2218/collab/mdwKqZo
I've divided this up into parts. Basically - as you explore the example and manipulate it in various ways there are a few themes that you should keep in the back of your mind:
1. SEQUENCE
2. HIERARCHY
3. ORGANIZATION (Semantics)
4. PATTERNS (Generalizable syntax patterns)
### HTML things
- Mess around with the sequence of different tags.
- How does _SEQUENCE_ affect the visual display of HTML elements?
> First, we changed the order of the <h1\> and the <p\> elements in the html code. We expected that this would make them switch places, and this is exactly what happened! Now the Meowmix song comes before the "meow meow meow meow" bit. So we learned that the sequence of elements corresponds with the sequence in which they appear on the actual web page.
- Change the hierarchy, the parent-child relationships between different tags.
- What are some ways that the _hierarchy_ of your tags will affect the end result / visual output?
> We removed the first <p\> child ("I like chicken...") from its <div\> container-top parent, so now it's an orphan. This means it appears on its own, outside of either of the two parent containers. This showed us that heirarchy controls which containers or sections a piece of content will appear in, or whether it will appear on its own, outside of these.
- Add/remove/manipulate various `elements`, `ids`, `classes`, `attributes`
- What did you do and what did you discover in terms of the GENERALIZABLE patterns?
> Elements: We learned that elements are the labels inside <\> tags. They determine how the different pieces of content will be formatted by the CSS code. We tested this by changing the "meow meow meow meow" <h1\> into a <p\> element, and the song lyrics into an <h1\> element, so now these two pieces of text have changed sizes. This is because the <h1\> and <p\> elements are formatted differently in the CSS code.
>
> ids: We learned that ids are used to designate a unique section in the html code. If we give a specific section of html code an id label, we can apply style changes to that section in the css code. For example, we coded the css style the for id: "intro" section to have a pink background. However, when we removed the id="intro" from the <section\>, the background changed to white again.
>
> Classes: We learned that classes perform a similar role to ids, but ids are for unique components whereas classes can be used again and again for different components. For example, we repeated the "container-top" class to include the "I like chicken..." text as well as the "meow meow meow meow" text, and gave this class a light green background in the CSS code. We found that both sections of text now have a green background because we can reuse the same class more than once.
>
>Attributes: We learned that attributes give additional information about one element, and there are many different ways to do this. For example, the src attribute links to a piece of media to be reproduced on a website and the width and height attributes specify the size, in pixels, in which it is reproduced. To demonstrate this, we added a gif of Pusheen below the meowmix song, using the aforementioned attributes to link to the gif and specify its size. We also added an alt attribute, which is used to describe the gif in words. This helps users to understand what the content is even if they can't see it.
- Try to add an embedded Youtube video in the `section#videos` tag.
- Before you do, take a guess as to what you expect to see as the visual result. Were your guesses correct?
> We tried to add the given Youtube video (multiple times), by removing the comment elements, but the video didn't show up.
>
> Our guesses were incorrect.
> 
We then tried a different code and it works by using the **iframe** element to embed a Youtube Video in the HTML.
> 
- Create some notes as _comments_ in this code.
- What are some ways that you can use comments to help you understand your code better?
> We can use comments to:
> > 1. Add notes or reminders for ourselves or other coders
> > 2. Help us find different elements (for example, we added comments to our code to label the header content, main content, table, reviews, and video)
> > 3. Track our progress
> > 4. Communicate with other coders! Coders can leave detailed comments for other coders to help them understand code written by others. This will helps with creating future editions or debugging.
- Take a look at the following:
- What is the generalizable syntax **_pattern_** between all these tags?
> The HTML syntax generally follows an "opening tag-content-closing tag" sequence. If we want to add an element, we need to define what kind of element it is in the opening and closing tags, and then specify more in the content between these two tags.
>
> The CSS style always starts with a tag referring to the element/id/class in question, and is then followed by curly brackets {}, which encompass the style information for the element.
>
> We can always learn more about how HTML and CSS work through Google and other online resources.
```html
<div id="mainStory">...</div>
<p class="important">Lorem ipsum...</p>
<span class="incorrect">Your answer</span>
<img src="https://placehold.it/50x50/4CAF50" alt="greenbox">
<input type="text" name="fullName" value="anonymous">
- Take a look at the following cheetsheets: [HTML5 Cheatsheet]
- Muck ar,re using some _new_ elements you haven't directly worked with in FCC.
- How did you go about learning how to utilize a new element (process)?
- How can different `elements`, `classes`, and `id`s help to _organize_ our html content?
### CSS things
- Take a look at the following _almanac_ of CSS selectors and properties: [30 CSS Selectors], [CSS Tricks Almanac] and use some new selectors and css properties to change the visual look of the page.
- Why do we have so many different kinds of CSS selectors available?
- Take a look at the following:
- What is the generalizable syntax **_pattern_** between all these css rules?
```css
div {
font-size: 10px;
}
div, span {
color: dodgerblue;
}
div#myFavorites {
text-decoration: underline;
}
div.incorrect {
text-decoration:line-through;
}
div span {
color: green;
}
div > span {
color: lime;
}
div:only-child {
font-family: cursive;
}
```
- Probably, no programmer knows every CSS rule and/or property by memory. I certainly don't, but I know a lot.
- How then, should you go about studying resources like [30 CSS Selectors] and [CSS Tricks Almanac] to help you become a more capable and efficient programmer?
> 1. Try to do something new (for example by using a new element) every time you code.
> 2. Be creative and keep an open mind.
> 3. There are so many online resources that can teach us more about writing CSS code. The very basic one is the [W3school](https://www.w3schools.com/css/default.asp) . This website includes all basic CSS styles.
> We can always find CSS inspriation online and search for specific examples. We can learn from others' work to see how to build an element. For example, if we wanted to know how to style a chat box, we could search "CSS style for chat box" and then learn from others' existing examples. We could also use the "inspect" function in Google Chrome to see how our favourite chat bot does it, and take inspiration from there.
### COMBINED and META things
- How might HTML sequence and hierarchy of tags affect your CSS rules?
- There are many things that can go wrong when you code an HTML/CSS page. Your HTML might be wrong. Your CSS might be wrong. It's pretty difficult to debug/fix when you have more than one thing wrong at the same time.
- Based on your understanding of how _sequence, hierarchy, syntax_ affects the page; What do you think are best practices to systematically fix errors in your code?
> We think the best way to find and fix errors in code is to make sure the code follows a clear, coherent structure. It also helps a lot to make sure it is formatted consistently in a way that makes it easy to read (for example by visually demonstrating hierarchy using spacing, and making sections easy to differentiate at a glance by leaving blank lines between them).
>
> A systematic way to find and fix errors in code could be:
> 1. Ensure the formatting is consistent and easy-to-read (for humans, at least)
> 2. Analyse the hierarchy to ensure it makes sense, and look for bugs that could be fixed by adjusting the hierarchy.
> 3. Analyse the sequence and ask whether this is the best sequence for the code, or if it could work better in a different order.
> 4. Slowly comb through the code looking for syntax errors and fixing them as you find them.
- Based on said understanding, what are some best practices to reduce errors _as you code?_
> 1. Use spacing to make sure your code is easy to read (for humans) so that you can easily find mistakes.
> 2. Establish a hierarchy and sequence that are structurally logical. It might help to first visually design your page by drawing it with a pencil and paper, placing different boxes inside one another and drawing arrows from one element to the next. This can help you visualise the structure you're trying to create and more easily translate it into strings of letters (code).
> 3. Check your work often so that you can spot bugs as they appear.
> 4. Commit key elements to memory so that you know what each line is supposed to look like. This can help you spot mistakes more easily.
> 5. Be patient and check over your syntax multiple times!
- What is the _STRENGTH_ of FCC exercises and what is the _LIMITATION_ with respect to learning and understanding?
> **Strength:**
> It makes coding more approachable by breaking it down into small steps, helping us build familiarity with one element at the time. In this way it lowers the knowledge/understanding threshold for beginning to code.
> **Limitation:**
> Because the lessons are so broken-down into smaller pieces, it can feel a bit fragmented. Also, because the instructions are so clear, you could move through a lot of the lessons by following the instructions without fully understanding what you're doing.
- What is the _STRENGTH_ of tinkering and what is the _LIMITATION_ with respect to your learning and understanding?
> **Strength:**
> It helps us practically apply coding in a low-pressure setting, deepen our knowledge by practically testing it, and pushes us to constantly think, compare, and summarise what we're learning. Learning as a group is also great for troubleshooting!
> **Limitation:**
> - It is a little difficult for us to Tinker together at the same time due to differences in time zones.
- What kinds of things did your group members learn, notice, experience that you did not and **why** do you think that is with respect to **HOW** you each respectively studied the materials?
>From this assignment, we have learned a lot about how different HTML elements work and the relationships between them. For example, we learned how sequence and hierarchy affects the visual display of HTML elements, the general syntax patterns in HTML and CSS coding, and how comments can help coders communicate with others - and their future selves!
>
> Working on this assignment as a group helped us all to learn more than we would have done individually, as we could all benefit from our collective insight, which was greater than any individual's knowledge.
>
>We also learned this lesson from multiple different angles, as each of us approached it slightly differently. For example, some of us had more fine-tuned coding know-how while others had better "bigger picture" insight, and we gained more knowledge from working on this assignment from all of our different perspectives at once.
### Tinker experience to Collaboration
This is your tinker activity. Play with this page and manipulate things to make it "yours" in terms of the understanding. The purpose is to give you a sandbox to try things in the guide, as well as your OWN ideas and inquiries.
This activity provides the anchor point for your collaborative discussion. As such:
1. Tackle each question _by yourself first_ so you can get a sense of what you understand and what you may not.
- TOTALLY okay to not be able to answer every question yourself at first.
- That's what the social collaboration is for.
2. Write out your responses to the questions to guide your collaborative work. I would like you to use Markdown format for your tinker-problem responses / submissions. (Using Word, Google Docs, is going to be very tricky and messy when it comes to writing CODE as notes.)
3. In your collaborative discussions, share your individual answers and use it as a starting point for your group discussions.
4. Use the collaboration tool like codepen to code together as you discuss and make examples of what you discovered together.
5. Generate a final _group_ response to each of the questions I ask above to come up with your _final answer_ as a team. It's less about what is right or wrong, more about being able to articulate what you learned and how you generated a deeper understanding by sharing what you individually understood into a bigger more comprehensive whole.
Additionally, you might want to also use that time (or times) together to help each other with the mini-problem or project of the week.
**_GOOD LUCK, HAPPY CODING!_**
[30 CSS Selectors]: https://code.tutsplus.com/tutorials/the-30-css-selectors-you-must-memorize--net-16048
[CSS Tricks Almanac]: https://css-tricks.com/almanac/
[HTML5 Cheatsheet]: https://websitesetup.org/html5-cheat-sheet/