Hi. If no margin is configured, what is the value of the margin that is established by default? In the exercise, you see the 3 red buttons at the end of the page with a separation between them when you do not have the margin set. Thanks in advance
The solution is in one of the following lessons, Margin Collapse. The margins do not overlap, but are added together. So, the .share elements would be 20px apart, 10px from each box.
If I decrease the padding of the .share class to 0 px, 0 px still the horizontal borders are far apart from the red elements. Why the padding doesn’t shrink ? How can I shrink it ?
I am trying to make the content of my website ‘narrow’. I’m trying to accomplish that by giving the entire a margin of 100px. Nested in the body i have my
which I set to width = 100%;
The result is the header ‘respects’ the margin in the right but not on the left side. Any idea why?
I have set the box-sizing: border-box; with the * selector.
BODY is not really meant to have margins, so might behave oddly in some devices when given them. Suggest create a page wrapper DIV inside the body and treat it with margins, or simply center it in the body.
#wrapper {
width: 95%
margin: 0 auto;
}
You can give the body a background color or even a pattern background with tiling of a 32 X 32 (or 16 X 16) image.
I’m not a big fan of the universal selector since it is a resource hog. My solution is to specify exactly which elements will have all those above properties.
I actually have that bit in my separate reset.css file as recommended in one of the lessons. The border is just to help me understand where the different elements are positioned while I play around with them. The order three properties are recommended best practice in a Codecademy lesson I believe
It seems I found the answer. As far as I understand my choice is to either have a navigation bar that is not fixed, fixed but not ‘narrow’ like the rest of the page or hard-coded to meet the same width as the body. However the last option will make it unresponsive, leading me to think the first option is the best,
I hope that link doesn’t break any rules, if it does I’m sorry.
For the sake of simplicity, I would shed anything that is not properly understood, whether recommended, or not. That includes the reset.css, and any properties you are not clear on, such as fixed position and z-index.
As mentioned earlier, margins and BODY are not good bedfellows. If anything, start by giving the body margin: 0, padding: 0, and border: none.
Just because we’ve seen something used in a lesson does not mean we have to use it, or that we even should. It complicates matters if we are are not clear on the box model, and cannot justify by our own reasoning and design consideration why something is implemented. It does not take a hammer and pry bar to construct a basic document. The simpler you keep it, the easier it is to see how fluidly HTML works.
With such a fluid markup language, it wouldn’t behoove it to have rules. The entire specification is built upon recommendations.
An HTML document is the scaffold of a user interface, or UX. The only logic is the author’s based upon considerations of usability. The first thing to wipe from the slate is any notion of rules. It’s a blank slate.
Recall how important it is that we are familiar with the default behavior of HTML elements. Which ones are blocks? Which ones are inline? Which ones have margins, or padding, or decoration, or bullets, or text-style, &c.?
We won’t learn that stuff trying to deconstruct a finished web page. It only adds to the mystery. If you want to tackle HTML, and master it, then kick aside the visual aspects and get into the structural aspects, especially where semantics and accessibility are concerned.
We can paste in chunks of HTML, or a complete page, and the validator will flag any markup that may be questionable or may contravene recommendations or guidelines. The latter, guidelines, is less so flagged, but there is some cautioning.
Validating against WAI-AAA levels is another concern, especially for web-facing pages. This is a whole 'nother world of HTML where we determine how accessible (therefore usable) our pages are to unsighted users with screen readers, or other developmentally challenged users who depend upon some form of assistive technology that has its roots in our very document.
Okay, so back to margins, and we should include padding in this discussion, as well. Margins have a negative effect on elements: the greater the margin, the narrower the element. Padding has a positive effect on elements: The greater the padding, the wider the element.
It’s this sort of information that we need to disseminate and play around with to get a complete handle on it. Boring, dull, banal, rudimentary, but… The core information we need to make HTML less of a wrestling match and more a directed approach to structuring a document.
Step back into this world and start working with basic documents, exploring one or two key elements in every way imaginable, without CSS.
Lists
unordered
ordered
definition
outline
Tables
for data
for layout
Forms
for information input
for user interaction
Block quotes
Semantic elements
document sectioning
content sectioning
In the earlier HTML snippet, HEADER and NAV are semantic sectioning elements. Their type describes their purpose. This goes a very long way to simplifying the code sample you posted earlier.
Consider the placement of the logo image in that sample. It uses a list item with an image and a link, which link is repeated in the next list item. The image size will undoubtedly be more than the font size. This will have a bearing later, when the CSS is brought into play.
Consider the earlier posted body, and how content can fall into one of the three contexts, header, main, and footer. We select them by type without the need to classify them.
So far we have four layers of document structure.
html
body
#wrapper
header main footer
There are very few style rules that will depend upon the high specificity of the wrapper, but it is there should a need ever arise. Add that to any selector and it will have a lot more sway. In the main, we would rather keep our selectors more generic with low specificity. It’s much less messy. We’ve digressed into CSS, so let’s not go too far.
I’m off to edit the earlier post, to give us something to lead off with in your exploration.
I think you misunderstood my question of whether the link i posted was against the rules. I linked to an answer I found to the issue on another website but I’m not sure if doing so is in accordance with the form rules here.
I do believe most of the concepts you mention. I am/was having some difficulties with fixed position but I think I get it now: fixed position elements are taken out of the html flow, which mean other elements ‘ignore’ them. And therefore it’s child element are de facto children of the fixed position element’s parent - is this correct?
Studying the MDN web docs is a great help too, thanks.
Are the margin-top and margin-bottom the same as the Google Doc/Microsoft Word functions of “Add space to the top/bottom of paragraph?” Is this the code that happens whenever I do that on a doc?