Get Online Fast money tips: Oktober 2015

Rabu, 28 Oktober 2015

How To Manipulate SVG Text - Vanseo Design

Posted: 27 Oct 2015 05:30 AM PDT

Last week I showed you how to create SVG text using the <text> element. In the examples I added x and y coordinates to position the text and the individual characters in a string of SVG text. There's more to the <text> element.

You aren't limited to the values of x and y attributes when working with SVG text. There are a few more attributes you can add to the <text> element and I'd like to talk abut them today.

The dx and dy Attributes

Let's start with the dx and dy attributes which are similar to x and y, except each represents a length relative to the previous character instead of an absolute position relative to the viewport.

Just like x and y, dx and dy take a list of lengths instead of a single length, though you can set a list of one length.

Let's pick up the example from last week and work in some values for dx and dy.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="0" dx="10,20,30,40,60" dy="10,20,30,40,50,60">This is some SVG Text</text>    </svg>

Here I set both x and y to 0 and then used a list of lengths on dx and dy. Notice as the value increases, the distance to the next character also increases. If you want the same space between characters you want to give dx and dy the same value as the previous value in the list.

One thing you may or may not have noticed is the lengths and the spacings between characters don't quite add up in the list above. If you map each length to a character, you would expect the "i" and "s" in "is" to be separated by 60px, which is the last value set.

The reason they aren't, is because those 60px separate the "i" from the space between the the words "This" and "is." Spaces count as characters.

Rotating SVG Characters

You can also rotate characters using the rotate attribute, which takes a list of numbers. Each number again represents a specific character.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="20" rotate="0,45,0,90,180,0">This is some SVG Text</text>    </svg>

Here I left x and y at 0 and added a list of numbers to the rotate attribute. The "T" will be rotated 0 degrees, the "H" will be rotated 45 degrees, and so on until we reach the end of the list and all remaining characters will be rotated 0 degrees.

Similar to the previous example, spaces count. Here the space between "This" and "is" is being rotated 180 degrees, which is why I added a 0 to the end of the list. Otherwise the rest of the characters would also be rotated 180 degrees and be upside down.

Again it's the individual characters that are being rotated and not the entire string of text. To rotate the entire string you would use a transform.

The textLength Attribute

The next attribute you can add is textLength which takes a single length as a value.

The textLength attribute lets you set the length of the text to a specific amount regardless of the size of the container.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="20" textLength="660">This is some SVG Text</text>    </svg>

Here I set textLength to the same width as the viewport so the text stretches from end to end. Note that the last character doesn't touch the right edge. That's because it's still inside an EM box. The right edge of the EM box is what touches the right edge of the viewport.

The characters are automatically spaced out so the text string fills the space. It's like justifying the content, except you can set the width on the fly.

You can also squish the characters together if you'd like, by setting a length smaller than what's necessary to display them all.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="20" textLength="50">This is some SVG Text</text>    </svg>

Naturally this isn't advisable with text you want people to read, but it could be used to create some interesting effects when the text doesn't need to be read.

One thing you may have noticed is that it was the space between characters that was adjusted with textLength, but the characters themselves remained the same size. You can change that with the last attribute specific to the textElement.

The lengthAdjust Attribute

The lengthAdjust attribute takes two values (spacing or spacingAndGlyphs), which determine what gets stretched or squished.

Of the two values, spacing is the default, which is why the previous examples used the space between characters to adjust to the the length specified. Here's a previous example with a change to lengthAdjust.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="20" textLength="660" lengthAdjust="spacingAndGlyphs">This is some SVG Text</text>    </svg>

The characters are now being stretched in addition to the spaces between them.

I mentioned earlier that because SVG text is rendered as a graphic element that you can apply things like strokes and fills , patterns and gradients. Any attribute you can add to SVG elements in general can also be applied to SVG text.

To prove that, here's an example where I've changed the fill to blue, added a red stroke, and doubled the stroke-width to 2.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible; font-size: 5em;">      <text x="240" y="120" stroke="red" stroke-width="2" fill="blue">SVG</text>    </svg>

Between this and the last post, I've shown quite a few ways to manipulate text and we still have more text related elements to get to. Let's stop here today, though.

Closing Thoughts

I hope you agree that SVG text is relatively easy to work with. Instead of a <rect> or a <circle> you create a <text> element inside your <svg> element, which is then rendered as a graphic with text that can be search and selected.

Even limiting ourselves to the attributes of the <text> element we can manipulate SVG text in a number of useful ways.

Next week I'll pick things up with the <tspan> element, which will allow you to style parts of your SVG text differently. The following week I'll show you to use the <tref> element, which allows you to reuse text across different <svg> elements.

Download a free sample from my book Design Fundamentals.

The post How To Manipulate SVG Text appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Rabu, 21 Oktober 2015

How To Work With SVG Text - Vanseo Design

How To Work With SVG Text

Posted: 20 Oct 2015 05:30 AM PDT

SVG text offers the best of both worlds. It's rendered like other graphic elements so you can do things like add strokes and fills that you can add to shapes, lines, and arrowheads. It's also packaged as XML character data, which means it's real text.

SVG text is accessible. You can select it, copy it, and paste it elsewhere. It can be read by screen readers and you can search for it in search engines. You can set it on a straight line, whether horizontal or vertical and you can even have the text follow a path of your own creation.

It's been awhile since I last talked about SVG and I hope I haven't kept you waiting too long for more. For the next few weeks I'll be talking again about scalable vector graphics and specifically how to work with SVG text.

If you're new to SVG, I recommend having a look at this article about how to work with SVG from the start of the year. If you want to check out some of the other articles in the series to this point, you can find them all here.

Characters, Glyphs, and Fonts

Before we get to the how let's define a few things.

Characters are the digital representation of the letters you want to display. SVG text is defined by a sequence of XML characters, which is why it can be searched for and selected. Each character is defined by specific unicode.

Glyphs are the visual representations of the characters. For example, the letter "f" can visually display with or without serifs or it can display in script. They would all be the same character, but each would be a different glyph.

Fonts are collections of glyphs. Glyphs drawn with a particular style will be collected together in a font, such as the Georgia or Helvetica. A font typically includes glyphs for the entire alphabet along with glyphs for numbers and it probably includes glyphs to represent ligatures. For example there might be a single glyph for the 'fi" pair.

In addition to a collection of glyphs, a font includes a font table which contains information necessary to display the different glyphs in the collection such as the size to display a glyph and where the glyph should be positioned. Font tables will also include information about things like the font weight.

Together the glyphs and font table are called font data.

The EM Box

Earlier in the year I talked about the SVG coordinate system and I talked about there being different coordinate systems for the canvas on which your SVG is drawn and the viewport through which you see the canvas.

There's another coordinate system specific to fonts. The geometric characteristics of different fonts are expressed within a coordinate system based on the EM box. The box around each glyph is 1em high and 1em wide. The box is called the design space and the coordinate system is called the design space coordinate system.

The space is given specific coordinates by dividing the EM box into a number of units per em. This number is a characteristic of the font and it's included in the information in the font table.

The (0,0) point is typically located along the left edge of the box, though usually not at the bottom left corner. You can see an example of this in the image at the start of this post.

The bottom of a roman capital letter is usually at the y=0 coordinate. Some letters, such as a lower case g or y, will have descenders that are still contained within the design space, but will have a negative value for their y-coordinate. That leads to y=0 being a point somewhere above the bottom of the design space.

SVG assumes that the font table will provide at least three font characteristics.

Ascent—the distance to the top of the EM box from the (0,0) point of the font
Descent—the distance to the bottom of the EM box from the (0,0) point of the font
Baseline table —the position of one of more baselines in the design space coordinate system

At the very least the font table is telling SVG how to locate glyphs inside the design space, though again it likely includes information about things like the weight of the font.

I don't want to get any more technical than what I've said so far. It's probably more than you wanted to know anyway. EM boxes and font tables will come up again later in the series when I talk about alignment and again when I talk about rendering SVG text along a path.

Before we can get to either though, I should probably show you how to create some SVG text.

The text Element

You create SVG text using the <text> element, which defines a graphic element consisting of text. Because the text is rendered the same way other SVG elements are rendered, you can do the same things to SVG text as you could to an SVG rectangle or circle or line.

You can transform SVG text in the coordinate space. You can fill it, add a stroke, and even reuse text across several elements. Before we get to those things let's start with a simple example.

1  2  3

<svg>    <text x="100" y="50">Some SVG Text</text>    </svg>

I defined a <text> element inside <svg> tags and I added x and y attributes that set a position to display the text within the viewport. Inside the <text> element's opening and closing tags I added the actual text that will display.

It's not the most exciting example, but I wanted to show you how easy it is to create text that's rendered as SVG. Let's build on the example.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0" y="0">Some SVG Text</text>    </svg>

In the next example I added a width and height to the the SVG element to set the size of the viewport. I added some inline styles to show the outline of the viewport and so we can see our text should it overflow the viewport. I also changed both x and y to 0 so the text will render at the origin of the viewport.

Notice where the text is displayed. You could probably guess it would be appear at the left edge of the viewport, but I bet you weren't expecting it to sit above the top of the viewport. Had I not changed the overflow property, we wouldn't even see it.

The reason is because y represents where the baseline of the text will be located. The baseline is included in the font table.

Here's the same example with some extra text so you can see how characters with descenders display.

A positive value for x will move the text to the right and a positive value for y will move it down. You'll generally want to set a positive value on y if you want people to see your text.

You can do more with x and y then set the starting position of the text. Each can take a list of coordinates (comma or space separated). The first coordinate in the list is the position of the first character of text, the second coordinate is the position of the second character, and so on.

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">     <text x="0,20,40,60,70" y="20">This is some SVG Text</text>    </svg>

Here I've given a list of coordinates for x. The first coordinate (0) is the x-position of the "T," the second coordinate (20) is the x-position of the "h," and so on. Once the list of lengths ends, any remaining character will display where it naturally follows the character before it.

It works in both directions as you can see in the next example where I've given both x and y a list of coordinates

1  2  3

<svg width="660" height="220" style="outline: 1px solid red; overflow: visible;">      <text x="0,20,40,60,70" y="0,20,40,60,70">This is some SVG</text>    </svg>

Let's leave things here and continue building on this example next week when I'll talk more about some additional attributes you can add to the <text> element.

Closing Thoughts

We're just getting started with SVG text and hopefully you can see how easy it is to create and position text as a scalable vector graphic.

The <text> element allows you to position all of your text and it allows you to position each character if you choose. There are more things you can do to manipulate how SVG text displays, which we'll get to.

I apologize for starting off with some dry information about glyphs and fonts and design coordinate space, but sometimes it's good to get that foundation in to help us understand later. I promise the majority of this series will offer a lot of examples showing what you can do with SVG text.

There's more to cover with the <text> element than what I've shown here and that's where we'll pick things up next week. I want to continue building on the examples and show you some of the other attributes you can add to the <text> element, including how you can stretch and squash the text so it fits into a space of your choosing.

Download a free sample from my book Design Fundamentals.

The post How To Work With SVG Text appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Rabu, 14 Oktober 2015

How To Use Sass Variables - Vanseo Design

How To Use Sass Variables

Posted: 13 Oct 2015 05:30 AM PDT

Think of all the times you might add the same color to different elements or classes in your CSS file and then think of all the fun you have changing everything when you decide another color would work better. Wouldn't you prefer to make the change once and have the rest update automatically?

Sass Variables are a way to store information that you want to reuse throughout your stylesheet. Variables are coming to CSS, but there's not much support at the moment and it's going to be awhile before you can use them. Fortunately they're available in Sass right now and they're easy to use.

A Simple Example Using Variables

To set a variable in Sass you give the variable a name beginning with a $.

1  2  3

$background    $primary-type-size    $heading_colo

All three are examples of variable names. Due to historical considerations and backwards compatibility, dashes and underscores are interchangeable. In other words $font-size and $font_size are the same variable and you can use either and even mix and match dashes and underscores throughout your document.

Setting the value of a variable is just as easy.

1  2  3  4

$background: #fff;    $primary-type-size: 1em;    $heading_type: &quot;helvetica&quot;;    $mainType: &quot;georgia&quot;;

The variable names above were arbitrary choices on my part and I'm not suggesting any are good names. My goal was to show you a few different ways you could name variables. You can use single words, dashes, underscores, and camel case notation.

Referencing variables in the rest of your code is also quite easy.

1  2  3  4  5  6

body {background: $background;}    h1 {font-family: $heading_type;}    p {      font-family: $mainType;      font-size: $primary-type-size;    }

All you have to do is use the variable where you would normally add a value. The Sass above will compile to:

1  2  3  4  5  6

body {background: #fff;}    h1 {font-family: &quot;helvetica&quot;;}    p {      font-family: &quot;georgia&quot;;      font-size: 1em;    }

If you later decide that Times New Roman would be a better font choice for your main copy, you just change the variable.

1	$primary-type-size: "times new roman";

When your .scss file (or .sass if you prefer the original syntax) compiles to .css, the value will be updated wherever you used the $primary-type-size variable.

In the examples here, I've only used each variable once, but I'm guessing you can see the power of variables given how often we all tend to use the same values throughout a stylesheet.

Allowed Characters in Variable Names

I haven't found any definitive information about what characters you can and can't use in variable names. The best I found comes from this Stack Overflow thread and it suggests the following are all allowed.

Any ASCII letter.
Any number 0–9 (as long as it is not the first character in the name).
Underscores and hyphens.
ASCII punctuation (!"#$%&'()*+,./:;<=>?@[]^{|}~) and spaces, if escaped with a backslash.
Unicode characters in the ranges 0080-D7FF, E000-FFFD, or 10000–10FFFF.
Unicode hex escape sequences such as 00E4

My advice would be to stick with simple names with simple characters. Use letters, numbers, dashes, and underscores and leave it at that. Name variables like you would classes and ids. Make them semantic and understandable to real people working in the code.

While I can't definitively tell you which characters are and aren't allowed, I can definitively say, I've never had a problem with any of the names I've chosen following the advice in the last paragraph.

Variable Scope

The variables in the previous examples have been global variables and they could be used anywhere throughout your Sass file. You can also define variables inside a selector and make them local variables.

When a variable is defined locally it's only available within the level of nested selectors where it's defined.

1  2  3  4  5  6  7  8  9  10

$background: #fff;    body {      $background: #ccc      background: $background;    }    article {      background: $background;    }

Here I've defined the variable $background in two places, once globally (outside of any selector) and once locally (inside the body selector). I've given each variable a different value. The global $background is white (#fff) and the local $background is a light gray (#ccc).

In this example, the body uses the local $background and gets a CSS background color of light gray (#ccc). The local variable overrides the global variable within the scope of the selector. The article selector uses the global $background and gets a background color of white (#fff).

You can define a global variable within a selector using !global.

1  2  3  4  5  6  7  8  9  10

$background: #fff;    body {      $background: #ccc !global;      background: $background;    }    article {      background: $background;    }

Here the $background variable is defined as global inside the body, which overwrites the global variable set initially. Both body and article will get a light gray background with this code.

Default Values in Variables

If you aren't sure if a variable has an assigned value you can make use of !default.

1	$main-font-size: 1em !default;

The idea is if there isn't yet a variable $main-font-size with an assigned value, then it will now be 1em, however, if the variable was previously assigned a value, use that value instead.

1  2  3  4

$main-font-size: 1.25em;    $main-font-size: 1em !default;    body {font-size: $main-font-size}

Normally when you list the same variable twice with different values, the one that comes second would be the one used. The !default flag, however, says to set the value on the second only if the variable doesn't yet have a value. Since the $main-font-size variable already had a value, Sass will use the initial value and compile to:

1	body {font-size: 1.25em;}

!default is useful in mixins (which I'll get to in the next round of this series), because it allows you to write a mixin with a !default value if no value is given, but it also allows that default to be overridden when a value is given.

Edwin Morris offers a use case that doesn't involve mixins, though it does involve @imports, which I'll also cover in the next round of this series.

Variable Interpolation

Interpolation is way to use the value of a variable as part of the name of a selector or property. You define the variable the same way, but you reference it using a different syntax.

1	#{$variable}

Like !default, interpolation is more useful with some things we haven't yet talked about, but here's a simple, if not exactly useful, example so you can see how interpolation works.

1  2  3  4  5  6  7

$name-1: background;    $name-2: border;    div {      #{$name-1}-color: #fff;      #{$name-2}-color: #000;    }

Here I defined two variables ($name–1, and $name–2) and then referenced them using interpolation syntax. The Sass compiles to:

1  2  3  4

div {      background-color: #fff;      border-color: #000;    }

You can see that the values of each variable replaces the interpolation syntax. Without the interpolation syntax, the values could only replace the variable where CSS values are normally allowed.

Hugo Giraudel offers some realistic use cases for interpolation in an article he wrote for Tuts+. It does talk about some Sass features, we haven't yet talked about here, but you can take a look if you want to know when you might use interpolation.

Closing Thoughts

Variables are one my favorite features of Sass. I think they're easy enough to understand and they're also easy work with. The hardest part is deciding what to name them.

Variables save time by keeping important values in a single location instead of spread throughout your stylesheet. They help make maintenance simple and they can help you set up prototypes that are quick and easy to change based on client feedback. I'll show you how in a future post.

Without question they're the main reason I stopped writing CSS and switched to writing Sass and I think they'll become a favorite of yours as well.

Let's leave Sass for now, though I'll come back with another round of posts soon. For the next few weeks I want to get back to SVG and talk about how you can work with text rendered as an SVG.

Download a free sample from my book Design Fundamentals.

The post How To Use Sass Variables appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now

Rabu, 07 Oktober 2015

The Pros and Cons of Nesting Your Sass Code - Vanseo Design

The Pros and Cons of Nesting Your Sass Code

Posted: 06 Oct 2015 05:30 AM PDT

Nesting can be a good way to organize your Sass code. It can also lead to specificity problems if you nest too deeply. You don't have to look to far to find people who'll tell you how wonderful nesting is or how the universe might cave in on itself if you attempt to nest your code.

The truth as usual is somewhere in between the extremes.

Last week I showed you how to nest your Sass code and throughout the post I mentioned you have to be careful not to nest too many levels deep. I also mentioned how nested Sass can help organize your code.

Today I want to talk about both. I want to show you the good and bad of nesting and hopefully leave you with the understanding that nesting as fine as long as you do it responsibly.

Let's start with the cons, because I think they're easier to explain and understand.

The Cons of Nested Sass

There's nothing specifically wrong with nesting, but you can run into problems if you nest your code too many levels deep.

For example say you have the following HTML and you want to style the link.

1  2  3  4  5  6  7

<main>      <div class="one">        <p class="two">Some text          <a href=""></a>        </p>      </div>    </main>

You probably know that a selector like main .one .two a is overly specific. The link you'd style in the selector is tightly coupled to a specific HTML structure, which is generally something to avoid.

However, if you nest your Sass you could be fooled into thinking your selector isn't specific at all

1  2  3  4  5  6  7

main {     .one {       .two {         a {color: red}       }   }    }

The Sass makes it appear as though you just styled a simple link, but once the Sass is compiled you end up with the same overly specific selector we saw without the nested Sass.

One problem with overly specific selectors is you have to write even more specific selectors to override them for that one case where you want an element to look different or your styles fall apart when you decide that an element inside one area of your design should be moved to another area of your design.

While I agree that nesting too many levels deep should be avoided, I don't think that makes nesting a bad thing or something to be avoided. True, it's easy to get carried away and end up with some very specific selectors, but it's just as easy to get carried away writing very specific selectors in CSS.

I'll paraphrase the title of an article by Roy Tomeij and say that nested Sass doesn't create bad code. Bad coders do. Yes it's easy to nest too many levels deep. The solution is easy. Don't do it. There's nothing forcing you to have deeply nested Sass code and once you understand you shouldn't, it's not that hard to avoid.

Most every other argument against nested Sass that I've come across is a variation of this one in the sense that the downside is a potential problem that isn't too hard to avoid if you follow best practices and try to write good code in general.

Mario Ricalde came up with the inception rule of limiting yourself to four levels of nesting, which makes my example above perfectly fine.

I try to aim for no more than three levels of nesting, which is about as much as I'm willing to chain selectors. In fact I try to keep nesting to two levels most of the time, only using three levels when I think it's necessary.

A good rule to follow is to nest only as deep as you're willing to chain selectors.

The Pros of Nesting

The cons might be avoidable, but what are the benefits of nested Sass? For me, the benefits are more readable and maintainable code.

For example here's some generic HTML that I commonly use when building menus and navigation bars. It's an unordered list with a class of global-navigation and inside are list items that contain links.

1  2  3  4  5  6

<ul class="global-navigation">     <li><a href=""></a</li>     <li><a href=""></a</li>     <li><a href=""></a</li>     <li><a href=""></a</li>    </il>

Here's how I might organize the Sass.

1  2  3  4  5  6  7  8  9  10  11  12  13

.global-navigation {     styles here     li {       styles here     }     a {       styles here       &:hover {styles here}     }  }

I use the class name as the parent selector and I nest styles for both the list items and the links. Notice that I didn't nest the link inside the list item here to keep from nesting too deeply.

I find a block of code like this easy to read and it keeps all the code for the global navigation in one place. It saves some typing in that I don't have to repeat .global-navigation in front of the other selectors too.

In the early days of Sass some thought that nesting your Sass with the same hierarchy as your HTML was a nice way to visualize your HTML in your Sass file, but that tends to lead to too much nesting and overly specific selectors.

The code above for a navigation bar isn't too deeply nested, saves some typing, and I find it generally easy to read. It also compiles to how I would have written the selectors as CSS before I knew about preprocessors.

1  2  3  4

.global-navigation {}    .global-navigation li {}    .global-navigation a {}    .global-navigation a:hover {}

BEM, SMACSS and Sass

If you prefer to write CSS using BEM or SMACSS, you have another reason to like nested Sass. Last week I mentioned how you could use an ampersand to refer to the parent selector and it works well with the naming conventions used by BEM and SMACSS.

I don't want to get too into the details of either here, but they both make use of naming conventions to write more modular CSS. For example you might write BEM with the following conventions.

1  2  3

.block {}    .block__element {}    .block__element--modifier {}

For a form and submit button that might look like the following:

1  2  3

.form {}    .form__submit {}    .form__submit--disabled {}

Using the ampersand as a parent reference you could write your Sass like this:

1  2  3  4  5

.form {        &__submit {          &--disabled { }        }  }

The second & (&–disabled) references its parent, which is .form__submit once the reference is replaced with the parent selector. The code will compile to:

1  2  3

.form {}    .form__submit {}    .form__submit--disabled {}

SMACSS uses a different naming convention, but you could similarly use the ampersand to nest your code if you're working with SMACSS.

Closing Thoughts

I prefer nesting because it helps me organize my code in a way that's more readable to me. Just be aware you can make a mess of Sass as easily as you can make a mess of CSS.

Most of the downsides of nested Sass come about from nesting too many levels deep. The downsides are more to do with poor coding than nesting in general. If you keep from nesting more than two or three levels deep, you should be ok.

Next week, I'll talk about another feature you're likely to use soon after you start working with Sass. I'll talk about using variables in Sass, which happens to be one of my favorite features of CSS preprocessors.

Download a free sample from my book Design Fundamentals.

The post The Pros and Cons of Nesting Your Sass Code appeared first on Vanseo Design.

This posting includes an audio/video/photo media file: Download Now