Improving Workflow #16

Closed
grayghostvisuals opened this Issue May 7, 2014 · 43 comments

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 7, 2014

Owner

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

Owner

FWeinb commented May 7, 2014

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

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 7, 2014

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>

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 7, 2014

Owner

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.

Owner

FWeinb commented May 7, 2014

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 7, 2014

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).

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

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 7, 2014

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...

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 7, 2014

@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

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

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 8, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 8, 2014

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

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

@lukasoppermann

This comment has been minimized.

Show comment
Hide comment
@lukasoppermann

lukasoppermann May 9, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 18, 2014

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.

TxHawks commented May 18, 2014

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

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 19, 2014

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">

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

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 19, 2014

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.

TxHawks commented May 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 20, 2014

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 =)

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 20, 2014

Owner

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

Owner

FWeinb commented May 20, 2014

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

@FWeinb

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 20, 2014

Owner

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

Owner

FWeinb commented May 20, 2014

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

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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?)

TxHawks commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 21, 2014

+1 for dynamic viewBox help.

+1 for dynamic viewBox help.

@FWeinb

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 21, 2014

Owner

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

Owner

FWeinb commented May 21, 2014

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

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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>

TxHawks commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 21, 2014

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

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

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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>

TxHawks commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 21, 2014

Owner

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.

Owner

FWeinb commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 21, 2014

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.
screenshot 2014-05-21 14 05 36

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.
screenshot 2014-05-21 14 05 36

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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 commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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

TxHawks commented May 21, 2014

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

@FWeinb

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 21, 2014

Owner

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?

Owner

FWeinb commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 21, 2014

Owner

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.

Owner

FWeinb commented May 21, 2014

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 added a commit that referenced this issue May 21, 2014

Update tests to include one for working defs
Account for changes made during the implementation of #16
@FWeinb

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 21, 2014

Owner

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

Owner

FWeinb commented May 21, 2014

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

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 21, 2014

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 commented May 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 22, 2014

@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.

TxHawks commented May 22, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 22, 2014

Owner

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.

Owner

FWeinb commented May 22, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 22, 2014

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

TxHawks commented May 22, 2014

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 22, 2014

Owner

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

Owner

FWeinb commented May 22, 2014

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

@TxHawks

This comment has been minimized.

Show comment
Hide comment
@TxHawks

TxHawks May 22, 2014

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

TxHawks commented May 22, 2014

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 22, 2014

Owner

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

Owner

FWeinb commented May 22, 2014

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

@chriscoyier

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 23, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 23, 2014

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>

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

This comment has been minimized.

Show comment
Hide comment
@FWeinb

FWeinb May 23, 2014

Owner

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

Owner

FWeinb commented May 23, 2014

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

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 23, 2014

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

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

@FWeinb

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals May 23, 2014

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

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

@chriscoyier

This comment has been minimized.

Show comment
Hide comment
@chriscoyier

chriscoyier May 23, 2014

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.

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.

@FWeinb FWeinb closed this Jun 20, 2014

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Jun 20, 2014

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment