Improving Workflow

[grayghostvisuals]

So, I finally got the SVG sprite to work, but since the width and height attributes are not set dynamically one has to enter them in manually otherwise the icons sit at the bottom of the viewport. Output is below, but here's a pen to view also… http://codepen.io/grayghostvisuals/pen/f8a269745f17d11e8ae77bec37630170

<svg viewBox="0 0 32 32">
  <defs>
    <g id="icon-cloud">
      <path d="M32 20.548c0-2.565-1.771-4.716-4.156-5.296-0.101-4.022-3.389-7.252-7.433-7.252-2.369 0-4.477 1.109-5.839 2.835-0.764-0.987-1.959-1.624-3.303-1.624-2.307 0-4.176 1.871-4.176 4.179 0 0.201 0.015 0.399 0.043 0.592-0.351-0.063-0.711-0.098-1.080-0.098-3.344-0-6.054 2.712-6.054 6.058 0 3.346 2.71 6.058 6.054 6.058l20.508-0c3.004-0.006 5.438-2.444 5.438-5.451z" fill="#000000"></path>
    </g>
    <g id="icon-info"><g></g>
      <path d="M16 0c-8.837 0-16 7.163-16 16s7.163 16 16 16 16-7.163 16-16-7.163-16-16-16zM16 29c-7.18 0-13-5.82-13-13s5.82-13 13-13 13 5.82 13 13-5.82 13-13 13zM14 8h4v4h-4zM20 24h-8v-2h2v-6h-2v-2h6v8h2z" fill="#000000"></path>
    </g>
    <g id="icon-menu"><g></g>
      <path d="M2 6h28v6h-28zM2 14h28v6h-28zM2 22h28v6h-28z" fill="#000000"></path>
    </g>
  </defs>
</svg>

<!--
Authors need to add these blocks below manually. 
Would be nice to add them in the SVG output file.
-->
<svg viewBox="0 0 32 32" class="svg-icon">
  <use xlink:href="#icon-cloud"></use>
</svg>

<svg viewBox="0 0 32 32" class="svg-icon">
  <use xlink:href="#icon-menu"></use>
</svg>

[FWeinb]

I am afraid that you might have misunderstood something here. How to use the generated SVG is explained here by Chris

[grayghostvisuals]

It would be nice if the output also included this block below so authors don't have to write it manually. You can obviously disagree here, but that's my thoughts so far.

<svg viewBox="0 0 32 32" class="svg-icon">
  <use xlink:href="#icon-menu"></use>
</svg>

[FWeinb]

Ok I see your point. Maybe we have to think about a solution for that. I will look into a way of doing it and add a option for that. I don't really want that to be the default behaviour, because that would mean to increase the file size for all users.

[grayghostvisuals]

Awesome. Also these svg's were taken directly from the output icomoon gave which resulted in an odd layout behavior where I had to monkey with the viewBox attribute (I coudn't get it to match exactly what @chriscoyier had in his article).

[chriscoyier]

Definitely don't include the <use> blocks in the same defs.svg file that gets created. That file is specifically to be linked up or included in the document somewhere all by itself, so then you can actually <use> the icons elsewhere.

I can see how that might be confusing... perhaps a demo.html file could be created that puts everything together and shows examples of the output or something... (like IcoMoon does). But that kinda complicates the simple thing that this grunt task does...

[grayghostvisuals]

@chriscoyier

Definitely don't include the blocks in the same defs.svg file that gets created. That file is specifically to be linked up or included in the document somewhere all by itself, so then you can actually the icons elsewhere.

Yup totally, but for demo purposes totally fine IMO. Just needs to be noted whether in an example file or a readme. Also could have sep output files (one for the defs and the other for the use blocks)

If you look at my demo you will notice when using icomoon svgs you must set the viewport box size to what they were made at. In my case 32 x 32. I can't do the values '0 0 100 100' like you have in your demo.

<svg viewBox="0 0 32 32" class="icon">
  <use xlink:href="#icon-cloud"></use>
</svg>

[chriscoyier]

That's interesting. What happens if you do use 0 0 100 100 - I would have guessed the output would be the same since they are both just a square - assuming you adjust the size of the actual <svg> in CSS or with width/height attributes.

[grayghostvisuals]

Using those values 0 0 100 100 makes the svg sit at the bottom of the viewport.

[lukasoppermann]

I would really appreciate this, maybe run a mustache template preview.html which is just an html file that has the svg included and hidden, and all the single svg icons in an svg+use-tag?

You could add some basic css in the head to make all icons black and a certain size.

[TxHawks]

Another use case to consider is that not all icons in the icon-system are the same size/aspect-ratio. The SVGs outputted by illustrator have a viewBox attribute on the tag itself, which of course, cannot be pulled into the defs. With large icon systems, it can become very cumbersome to remember which viewBox value goes with which icon (especially in large teams).

My suggestion would be to use a data-attribute like solution, by adding the original SVG's viewBox data to every tag under the defs. Maybe using the desc attribute (http://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements). This way we can maybe use js to inject the correct viewBox sizes to the SVGs, or in the very least have a handy reference.

[chriscoyier]

I wonder if SVG allows data-* attribute on stuff like HTML does? Even if it doesn't, it probably wouldn't hurt anything.

<g data-viewport="0 0 80 100">

[TxHawks]

That was my initial idea, but from what I managed to see, it's not in the spec (see this stack overflow, which is where I took the desc attribute idea from). They do suggest it's possible to add namespaces, but that seems a whole lot more cumbersome than just using desc to me.

[chriscoyier]

Using <desc> would be weird I think. See Tip 4 here: http://www.sitepoint.com/tips-accessible-svg/

the namespaced attributes seems like a possibility but also possibly easy to screw up as an author because of the required extra attribute on the <svg>. I can't imagine there is any downside to just using data-* even if it's not in the spec. Specs are malleable =)

[FWeinb]

I will include an option to generate a separate usage.html and include the data-viewBox attribute @chriscoyier mentioned.

[FWeinb]

I added a includedemo option in 0.1.0. I would like to get some feedback if this option is enough.

[TxHawks]

The demo html is nice to have, but I think the data attribute will be much more useful, as it will allow for an automated process of including the correct viewBox (with a grunt task maybe?)

[grayghostvisuals]

+1 for dynamic viewBox help.

[FWeinb]

How would you like it to look? Just add a data-viewBox and when where?

[TxHawks]

I'd say data-viewBox on every g based on the viewBox attribute of the original svg.

something like:

<svg>
  <defs>
    <g id="icon-1" data-viewBox="0 0 40 20">
         [paths]
    </g>
    <g id="icon-2" data-viewBox="0 25 12 38">
         [paths]
    </g>
  </defs>
</svg>

[grayghostvisuals]

@TxHawks
Yes and as I stated above w/icomoon not all svgs are created w/an equal viewBox.

[TxHawks]

I think I have a better idea.

Maybe the issue stems from <g> being the wrong tag to represent icons to begin width. I may be reading the spec all wrong, but the <symbol> tag seems more appropriate for representing an icon than the <g> tag (Icons are reusable symbols, after all, not mere groups of paths).

But their big advantage is not the better semantics, but rather that they can hold many of the attributes and elements an svg tag itself can hold - including - its own, independent, viewBox attribute.

Moreover, If I'm reading the spec correctly, the <symbol> element's content model allows the use of <title> and <desc>, which would be great for accessibility.

Am I missing something?

To sum up, my proposal is that the structure be changed to:

<svg>
  <defs>
    <symbol id="icon1"  
            viewBox="original-file's-viewBox"  
            title="original-file's-title" 
            desc="original-file's-desc">

      [paths]

    </symbol>
  </defs>
</svg>

[FWeinb]

Thank you for the research you are doing! It is great. I am using this structure now and it is working!
The only issue is that, If we set the viewBox on the <symbol> tag. We can't use another viewBox in the <use>-block. without removing it from the <symbol>

Here is a pen with the proposed syntax.

[grayghostvisuals]

Syntax is nice. Also If you adjust the size seen here w/icomoon you can actually make the viewport 0 0 100 100. By default it is 32 which was my problem init.

[TxHawks]

I can't see why you would want to change the viewBox in the use block. What would be a reason to want to do that?

[TxHawks]

My only addition to the proposed syntax in the pen, is also adding the original title and desc, as I suggested before

[FWeinb]

I am just passing the arguments from the source svg to the <symbol>-block. So if you have a viewBox, titleor desc on the svg itself it will be written to the symbol.
Should I implement a fallback to the filename if the title attribute is not set on the svg?

[FWeinb]

I just read the spec again and saw that title and desc aren‘t attributes. So I will read the title from the first title-tag of the source svg and include a title and desc-tag. for the title i will fallback to the filename.

[FWeinb]

I pushed version 0.2.0 to npm so you can test it. Any other improvements?

[TxHawks]

Thanks for being so responsive on this. Your work is really great.

I just tested it, and it seems to work perfectly. My only reservation is about the implementation of the fix to #1, but more on that there.

Thanks again for all your work

[TxHawks]

@chriscoyier, since your css-tricks article is probably the go-to guide on SVG icon systems, it may be a good idea to update it with the symbol syntax, so that people aren't confused when svgstore generates a different output than what's in the guide.

[FWeinb]

It might even be possible to drop the <defs>-tag and just use <symbol>s for everything. The spec states that:

A ‘symbol’ element itself is not rendered. Only instances of a ‘symbol’ element (i.e., a reference to a ‘symbol’ by a ‘use’ element) are rendered.

So it is exactly what we want to do.

[TxHawks]

Sounds about right... it would also mean that we can have a <defs> block for gradients and clipping paths from the original svgs, to be used in the symbols

[FWeinb]

Right. But even than we need to use visibility:hidden like discussed in #1.

[TxHawks]

True, but still more semantic. If potential performance penalty in large and complex svg systems isn't too big, it's probably the best solution.

Otherwise, two svgs, one for <defs> and one for <symbol>s still sounds pretty reasonable to me

[FWeinb]

Okay, I changed this in 0.2.1 so <symbol>s are written tot he <svg>.

[chriscoyier]

Seems like a good change to me, especially with putting the viewBox on the <symbol>, that makes it way easier to use later in the HTML.

[grayghostvisuals]

Am I the only one that would like to see this line below outputted still? Ok I'm lazy, that's true, but I don't wanna type this out all the time. Copy and paste yo and not from a README or googling the syntax. Pleases and thank you's w/cherries on top.

<svg><use xlink:href="#icon-cloud" /></svg>

[FWeinb]

Use the includedemo option and you will get a demo html. That should be ease enough.

[grayghostvisuals]

Oh sweet! Definitely need to add that to the README even though I see it listed in the changelog.

[FWeinb]

It is explained in the README: https://github.com/FWeinb/grunt-svgstore#optionsincludedemo-since-010

[grayghostvisuals]

yep I missed it. I would still include a code block sample anyways. thanks again.

[chriscoyier]

It can't go in the final output file cause then that file isn't production-use ready, it's just a demo. I like how the demo is optional. Just my 2 cents.

[grayghostvisuals]

yay! 🎆 thanks @FWeinb and everyone else for the great collab to make this happen.