Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

edit and shorten SVG blog #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

edit and shorten SVG blog #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 6 additions & 10 deletions predictable-svg-xml.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,21 +1,17 @@
# Predictable SVGs: Knowing just enough XML

I do a lot of work with SVGs at IBM.

We make them available to be used in very simply because they're used as icons in the product we build.
There's only a small subset of things that these SVG icons need to do but here are the two important ones:
I do a lot of work with SVGs at IBM Bluemix.

Our SVG icons need to be able to change their size and color with CSS. That's it.

So when it comes down to modifying SVG icons, there are only 4 XML attributes I wanted to understand first: `fill`, `viewBox`, `width` and `height`.

The only way I've been able to get consistent, predictable results is when I ensure that `viewBox`, `width` and `height` attributes are always together on the `<svg>` wrapping element.
With that said, all I need to use are: `fill`, `viewBox`, `width` and `height`.

### Forget everything you know

Okay, well, not _everything_ but just here me out...

I know you know these attributes work together in a **coordinate system**...but I've had to tell myself, "Hey, forget about that for now. You're not doing anything too fancy with these SVGs."
But for some reason, I always have to use `viewBox`, `width` and `height` together to ensure I get predictable and consistent modification results.

### Here's what _seems_ to happen...

Expand All @@ -31,10 +27,10 @@ Get ready for some air quotes.

We can control "sizing" with `width` and `height`.

- You can override these attribtue values with CSS
- The SVG will keep its aspect ratio intact, so you won't see any weird stretching or shrinking when you do weird size changes.
- You can override these attribute values with CSS
- The SVG will keep its aspect ratio intact (this means no stretching or sizing side-effects)

We can control the "parts of the SVG you actually see" with `viewBox`.
We can control the "crop" of the SVG with `viewBox` (this is the part of the SVG you actually see with your eyeballs)

- `viewBox` is like defining the size and position of a "window" to view the SVG icon. For example:
- A "window" that is too small will show a small part of the SVG.
Expand Down