Not all links of a document must be in a <nav> element, which is intended only for major block of navigation links; typically the <footer> element often has a list of links that don’t need to be in a <nav> element.
You can use the address element (more descriptive):
<p>Coded by <a href="https://www.freecodecamp.org/camper-fcc">Camper-FCC</a></p>
<a href="https://gitlab.com/camper-fcc/tribute"><span class="fa fa-gitlab"></span>Code</a>
The HTML <address> element supplies contact information for its nearest <article> or <body> ancestor; in the latter case, it applies to the whole document.
To represent an arbitrary address, one that is not related to the contact information, use a <p> element rather than the <address> element.
This element should not contain more information than the contact information, like a publication date (which belongs in a element).
Typically an <address> element can be placed inside the <footer> element of the current section, if any.
You can contact author at <a href="http://www.somedomain.com/contact">www.somedomain.com</a>.<br>
If you see any bugs, please <a href="mailto:firstname.lastname@example.org">contact webmaster</a>.<br>
You may also want to visit us:<br>
1981 Landings Drive<br>
Mountain View, CA 94043-0801<br>
You can use a Blockquote element (more descriptive)
<p>"Sometimes nature rewards the patient onlooker with a special treat. The latest occurred while watching a raccoon enjoying an afternoon nap nested in an elm. Sharing the sight from a nearby limb was an energetic Tufted Titmouse. In moments, the Titmouse flew down onto the Raccoon’s limb and hopped along until it was right at the Coon’s furry backside - then vaulted up onto his back. No reaction at all from either. The Coon stayed motionless, while the Titmouse pecked around, seeming to find little bits to eat on his friend’s back. Then, he hopped off and repeated his search along the Coon’s ample backside. A symbiotic relationship here?"</p>
<p class="byline">− <a href="http://visitwimberley.com/critters/raccoon1.shtml">Lewis Smith</a></p>
The HTML <blockquote> Element (or HTML Block Quotation Element) indicates that the enclosed text is an extended quotation. Usually, this is rendered visually by indentation (see Notes for how to change it). A URL for the source of the quotation may be given using the cite attribute, while a text representation of the source can be given using the <cite> element.
<p>This is a quotation taken from
the Mozilla Developer Center.</p>
The features of the project you list camper, are amazing. I learned a lot from reading them. Love the color contrast test link. Being a responsive site I would maybe make the font of the timeline text larger. It is a bit hard to read and in my opinion could look better in larger font on a larger screen.
@missKatiaPunter Thanks for the suggestion. This is something I’m struggling with and I even asked about it here in the forum recently. If you have a moment, answering these questions may help me understand it better:
Are you using a 4k monitor? If not, what is the viewport size when the text is difficult to read? It should be showing as 16px.
Is the sentence, “These facts and more about the amazing raccoon can be found in the Wikipedia article” more readable for you or is it also too small?
Can you send a screenshot so I know what it looks like? Or, maybe even more helpful than a screenshot, can you tell me what font size you think will be more readable?
The main problem I’m having is viewing the site on larger screens or viewports. I only have access to my 1600px width screen, so it’s proving to be difficult to understand what my site looks like on larger screen sizes. I’ve tried using Chrome DevTools, but I can’t tell if what I’m seeing is accurate because it looks like the font is readable on larger screen sizes, especially when I zoom the view to 100%, but I’m doubtful what I’m seeing is the same as what someone sees on a 4k monitor, for instance.
Also, please share any resources you find about this. I’m having trouble finding updated resources about font sizes and viewports.
From the comfort of your normal desktop browser, you have access to do live testing on a huge array of browsers on all sorts of platforms. They run the machines for you, and you just interact with them. It’s kinda magical.
Other Great Stuff about CrossBrowserTesting
While Live Testing, you can record a video of what you’re seeing/doing. I find this useful in customer support where I can clearly demonstrate something in a particular browser.
You can enable a local connection, meaning you can test sites on your localhost. I use this to test my local CodePen dev site!
You can take screenshots in a whole bunch of browsers at once, for quick testing across a wide variety of browsers.
You can run Selenium tests in a variety of different browser contexts.
@Diego_Perez Thanks! I’m familiar with tools like that. When I view my sites with these tools on larger viewports, they look fine to me but I feel like it’s not the same as if I were looking at the sites on a physical monitor.
I think the overall problem is that I’m not understanding how to code font sizes to accommodate all screen sizes and shapes. For instance, when I use the viewport units (vw, vh, vmin, and vmax), I get strange results at certain sizes. This makes me think that I have to combine them with media queries in order to get good results. However, I thought those units were created to span across a large spectrum of viewport sizes so media queries wouldn’t be necessary? If media queries are needed, then how do I know I’m hitting all of the important breakpoints?
Also, what are recommended font sizes for varying types of text? Are there any industry standards or best practices for paragraph text font size on 4k monitors or heading text size on 1440px viewports, for instance? Maybe something that says, “When designing for 4k monitors, paragraph text should be no smaller than 24px. If it’s smaller, it’s too difficult for most people to read” or something like that.
Does 16px font size look the same in all viewports? Does it look too big in smaller viewports or too small in larger viewports? There’s a lot of subjectivity in this because everyone prefers different sizes. However, maybe there are standards/research out there to help designers figure things out.
I know some of this is designer preference and what fits with a particular design, but I’m really hoping there’s a good resource out there that goes into more detail about this. So far, the only resources I’ve found are introducing font size units rather than explaining how they’re used in production.
Does this make sense or am I focusing too much on something that’s not a problem?