Connectivity to Typekit

Hello all,

I have been reading up on how to connect my typekit to my css but nothing seems to be changing the font style. I have a basic <nav> set up and I am trying to fancy it up a bit with fira-sans. I downloaded the font, embedded the code from typekit and I used proper notations like font-family:"fira-sans". I am working on DW and have CC, so I feel like it should all be hooked up. Any advice would be much appreciated.

Thank you community,
V

 

Hi there MaxTitan,

which of the thirty two font varieties are you actually using?

What browser are you using for your tests?

Can you put a test page online, to enable members to assess your problems?

​

coothead

 

At minimum, post some code-samples (both the CSS and the HTML) here

 

1. Hey guys, I figured out how to make it work with Google fonts. I actually have a much simpler problem. How do I center my .learnMore class? here is the sample code.
2. I had to mess with the px so that my important boxes were aligned nicely. I can't help but think there is a way to just type up and have them centered within a 1020px container without my having to guess the right amount of px so that it fits. Any suggestions?

p.s. How can I share a test page with you?



HTML

<div class="importantText">
<h1>The world of commerce needs craftsmen.</h1>
<p>Commerce is complex. You need the skills of a craftsmen to get it right. You need Pitney Bowes, the Craftsmen of Commerce&trade;.</p>
<p class="learnMore"><a href="#">Learn More</a></p>
</div>

CSS

.importantText {
padding:60px 0;
clear:both;
}

.importantText h1 {
font-size:40px;
text-align:center;
}

.importantText p {
font-size:21px;
font-weight:lighter;
text-align:center;
}

.learnMore {
text-align:center;
margin:0 auto;
display:inline-block;
border:1px solid #000;
background-color:#EA696B;
width:200px;
border-radius:10px;
}

 

just posted an update

 

just posted an update

 

http://www.pitneybowes.com/us I inspected this code, but could not get anywhere.

 

Not tested:
Instead of setting display to inline-block, set it to table.

cheers,

gary

 

For the boxes at the bottom, have a look at display: flex; https://css-tricks.com/snippets/css/a-guide-to-flexbox/
As long as you don't care too much for older browsers, that is.

 

Hey Gary,

That didn't do the trick. You know how when you create a container with a certain width and place it within an element so the element can have a full width display. And you make your .container {margin:0 auto; } it balance's the page. hmmm :/ thanks for the help.

 

This is cool, thank you sir.

 

1) Not sure why anyone here seems to think you need to dick around with anything BUT display:inline-block on the anchor.

2) Not sure why that would be the H1 since I doubt other content on the page would be subsections of that.

3) Not sure what makes a single anchor with two words unconnected to the flow text qualify as a paragraph gramatically.

4) Do NOT declare font sizes in pixels, it's a giant middle finger to usability. This likely means you need to take some time to read the WCAG and understand why we're supposed to be using EM not PX for fonts and paddings.

5) You're also playing with illegible colour contrasts from what I'm seeing in that picture. NONE of that white on grey is going to be the least bit useful to around 30% of the potential audience of people using the web. Again, read the WCAG, or if that's too complex use a tool like this one to make sure you aren't flipping off your users out of ignorance:

http://webaim.org/resources/contrastchecker/

6) If you change the font-size, change the line-height as you cannot trust it to EVER inherit properly. (dunno how you are setting that elsewhere, but if it's that "no metric" crap halfwits at places like Sitepoint claims works, they're full of shit). At that point I just redeclare the whole condensed font property since it's nearly as many characters and makes it clearer what is being used.

7) I'd AVOID using webfonts on, well... flow text (grammatical paragraphs) and the menu. IF you do resort to them use an eye-dropper and for the love of ghu avoid font-weights other than normal and bold as they can wreak havoc with how browsers handle them!

8) Avoid declaring fixed widths on elements with text inside them, it's just a headache later on when it's time to think responsive.

So rather than screwing around with a paragraph to center that:

HTML:

<div class="importantText">
	<h2>The world of commerce needs craftsmen.</h2>
	<p>
		Commerce is complex. You need the skills of a craftsmen to get it right. You need Pitney Bowes, the Craftsmen of Commerce&trade;.
	</p>
	<a href="#" class="learnMore">Learn More</a>
</div>

Code (markup):

CSS:

.importantText {
	clear:both;
	text-align:center;
	font:normal 125%/150% arial,helvetica,sans-serif;
}

.importantText,
.importantText p {
	padding:1em 0;
}

.importantText h2 {
	font:bold 200%/120% arial,helvetica,sans-serif;
}

.learnMore {
	display:inline-block;
	padding:0.25em 1.5em;
	text-decoration:none;
	border:1px solid #000;
	background:#EA696B;
	color:#FFF;
	-webkit-border-radius:0.5em;
	border-radius:0.5em;
}

Code (markup):

Again changing to dynamic fonts so everything auto-sizes based off the system metric (os or browser default size). Of course that will only work assuming that you have EM's site wide as even one font-size in PX on a parent element (including body) will shtup the entire process!

Without knowing what the content in the bottom boxes are, it's hard to say how I'd style them, though since there's four of them I don't see why you'd be doing anything more than float:left; width:25%; on them, assuming that you have an outer wrapper around everything that's constraining the width as a semi-fluid layout. (or fixed, but fixed width is for halfwits, morons and fools).

That's why it's generally better practice to code all the content semantically BEFORE you start dicking around with styling it or worrying about what anything is going to look like. Say what things ARE in your markup before you start screwing around with layout.

Guessing WILDLY since there's no actual content or reasonable facsimile of future content, there is likely little reason for the code of that to be significantly more than:

<div id="top" class="widthWrapper">

	<h1>
		<a href="/">
			Site Title
			<span><!-- image sandbag --></span>
		</a>
	</h1>

	<ul id="mainMenu">
		<li><a href="shop">Shop</a></li>
		<li><a href="account">My Account</a></li>
		<li><a href="support">Support</a></li>
		<li><a href="search">Search</a></li>
		<li><a href="menu">Menu</a></li>
	</ul>

	<div class="important">
		<h2>The world of commerce needs craftsmen.</h2>
		<p>
			Commerce is complex. You need the skills of a craftsmen to get it right. You need Pitney Bowes, the Craftsmen of Commerce&trade;.
		</p>
		<a href="#" class="learnMore">Learn More</a>
	<!-- .important --></div>

<!-- #top.widthWrapper --></div>

<div id="featured"><div class="widthWrapper">

	<div class="subSection">
		<hr><!-- remove if this would have a numbered heading -->
		Something, get some actual content here so we know what the **** we are trying to style!
	<!-- .subSection --></div>


	<div class="subSection">
		<hr><!-- remove if this would have a numbered heading -->
		Something, get some actual content here so we know what the **** we are trying to style!
	<!-- .subSection --></div>

	<div class="subSection">
		<hr><!-- remove if this would have a numbered heading -->
		Something, get some actual content here so we know what the **** we are trying to style!
	<!-- .subSection --></div>

	<div class="subSection">
		<hr><!-- remove if this would have a numbered heading -->
		Something, get some actual content here so we know what the **** we are trying to style!
	<!-- .subSection --></div>

<!-- .widthWrapper, #featured	--></div></div>

Code (markup):

That bottom section is somewhat what I like to call "design concepts that have ZERO business on a legitimate website" -- If I HAD to do that with equal height and no clue what the content was, these days I'd use flexbox as @PoPSiCLe suggested... they aren't equal heights in IE9/earlier, OH WELL!. Damned shame the improperly named "CSS grids" aren't real world deployable since Microsoft suggested it, and as such Mozilla is unlikely to even try implementing it this century because of their "nananana foo-foo rage against the man rawrz Microsofts izzez teh evils" dirty hippy attitude... even when it's been accepted as a draft by the W3C

But again, there's a LOT of guessing there since there's no blasted CONTENT or at bare minimum a realistic facsimile of future content to work with... Stuff that should be coded with semantic markup LONG before DIV are ever added to the code.... Which if you use things like numbered headings and horizontal rules properly, makes the nav, section, article, header, footer and all that other HTML 5 allegedly semantic code bloat BS completely redundant!

See my article here:
http://www.cutcodedown.com/article/progressive_enhancement

For more on what I'm talking about and the approach to building a page I advocate; to break it down fast:

1) Start with the CONTENT or a facsimile of future content in a flat text editor as if HTML doesn't even exist.

2) Mark up that CONTENT saying what things are to enhance the logical document structure (numbered headings and horizontal rules saying where sections and subsections start) and saying what things ARE (lists, paragraphs, etc) and NOT WHAT THEY LOOK LIKE! -- since that's the semantics stage DIV, SPAN, id's and classes have no business in there at this stage. This is your basis that search engines, non-visual UA's like screen readers or braille readers will get, as well as other forms of legacy accessibility devices or even just REALLY outdated browsers. Some security minded tinfoil hat types will also ONLY see this!

3) Create a pre CSS3 compatible desktop screen layout FIRST, since that's what we CAN'T target with media queries. The people saying "mobile first" clearly have no clue what the **** they are talking about since you should start with what you CAN'T customize. This is where you can start adding DIV, SPAN, classes and ID's as needed. If possible this layout should be semi-fluid (adjusting between a min and max-width) and Elastic (widths stated in EM) with dynamic fonts (font sizes in % or EM). That way everything expands or shrinks to the user's browser or OS preference so they don't have to dive for the zoom as much!

4) Use media queries to add/remove columns, and generally adjust the layout as needed to fit smaller displays, and if there's enough content possibly add more columns or re-arrange to use more of the screen so people on really big displays don't have to scroll as much; keep in mind that a max-width should be maintained as really long lines can compromise ease of reading. I like to use taller line-heights (150% or more) on flow text to help address that.

It's called "CONTENT FIRST" design, and is an integral part of progressive enhancement and minimalist markup.

I have an article on the latter of those here:
http://www.cutcodedown.com/article/minimalist_semantic_markup

Progressive enhancement provides another concept called "graceful degradation" and is there to make sure that the resulting page is as accessible as possible to as many people as possible; a concept lost on the art faygelah's screwing around in Photoshop (It's ok for me to say art faygelah, I am one) or the ignorant twits dicking around with gibberish halfwit asshattery like bootcrap, yui, blueprint, grids or any other "framework" rubbish.. It's very easy to get so caught up on your visual layout, you neglect the actual intent of HTML, much less the reason HTML and CSS exist in the first place!

Rabbi Tuckman: Faygelahs?
Robin: No, we're straight. Just Merry!

In any case, hope this helps. In case you couldn't tell I have a very different way of looking at things compared to the "status quo" crowd that just blindly copypasta's code from decade and a half out of date tutorials.

 

Thanks for the over spree of knowledge. I have been looking into em's and I do know of % I simply am just just trying to recreate an existing website to increase my skills seeing as I am a designer first, latter developer. As far as color I am not paying any attention to it really and this is not the final draft, I hope you are relieved. There is a lot here I agree with you, even though I am a white belt a lot of what I have been reading is like do what you want, but doesn't make sense to start with mobile first. I have read 1 article about legibility and how some are actually tailoring more towards the older generation, which I think is a great idea. As for the line height, good tip, lots of good tips here. I appreciate you taking the time to school a young grasshopper. This is the site I am re-making from http://www.pitneybowes.com/us.