Is it time to revisit font icons
dana.ayotte at gmail.com
Mon Apr 18 17:49:39 UTC 2016
Alan it sounds like you’re saying that fill/stroke/other appearance attributes created in AI get converted into style attributes when the SVG is saved, is that right?
Can anyone recommend a good way to create SVGs that would not generate style attributes? Is this something that can be set in AI as a preference? I took a look at the SVG Options dialog that appears when saving an SVG and I can’t see any obvious way to do this. Would the SVG code have to be altered prior to saving?
> On Apr 15, 2016, at 9:15 AM, Harnum, Alan <aharnum at ocadu.ca> wrote:
> Hi John,
> Comments from my own experience…
> Styling with CSS and default element style attributes
> While it may vary in certain browsers (esp older ones), I believe the standard these days is that any CSS styles should override style attributes specified as part of the SVG’s markup (“fill” or “stroke” attribute, etc), but not those specified in a “style” attribute.
> Here’s a quick fiddle showing this (the first circle has fill/stroke/etc specified only as attributes and the CSS gets applied, the second has attributes specified in a “style” attribute and these beat the CSS): https://jsfiddle.net/b183p5dh/4/ <https://jsfiddle.net/b183p5dh/4/>
> So it’s typically safe to set default values for SVG elements as long as they’re only part of the attribute markup, rather than an element “style” attribute (which will cause them to win out over any external CSS). I’m guessing Adobe Illustrator might use the “style” attribute approach with what it generates.
> Storing inline SVGs for reuse
> I think the biggest challenge with storing SVGs separately in Git would be updating them when desired across whatever sites they’re used on. I wonder if looking at approaches like https://github.com/iconic/SVGInjector <https://github.com/iconic/SVGInjector> might not be worthwhile, or a preprocessor function for things like the ILDH where we’re generating a static site.
> From: fluid-work <fluid-work-bounces at lists.idrc.ocad.ca <mailto:fluid-work-bounces at lists.idrc.ocad.ca>> on behalf of "Hung, Jonathan" <jhung at ocadu.ca <mailto:jhung at ocadu.ca>>
> Date: Thursday, April 14, 2016 at 4:06 PM
> To: Fluid Work <fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>>
> Subject: Re: Is it time to revisit font icons
> I’m digging up this email thread now that I’ve spent some time using SVGs for the Quality Infrastructure demo.
> Here are some personal remarks:
> - being able to style an SVG using CSS is very desirable and convenient. I was able to easily add contrast styling for graphs, logos, and button icons with a few lines of CSS.
> - if a SVG specifies a default width, height, and colour (which is typical of most SVGs created using Adobe Illustrator), you would not be able to override it with CSS as the default values have higher priority. I had to manually delete the values from the <SVG> element in order for custom CSS to work.
> - positioning and styling SVGs is much more convenient and predictable than with icon fonts.
> Bottom line: I really liked using SVGs inline with the HTML. It was easy to style and use.
> Is it a viable strategy to track *.SVG files separately in git, and then copy and past the SVG element into HTML as needed?
> - Jon.
> JONATHAN HUNG
> INCLUSIVE DESIGNER, IDRC
> T: 416 977 6000 x3951 <>
> F: 416 977 9844 <>
> E: jhung at ocadu.ca <mailto:jhung at ocadu.ca>
> OCAD UNIVERSITY
> Inclusive Design Research Centre
> 205 Richmond Street W. 2nd Floor, Toronto, ON, M5V 1V3
> www.ocadu.ca <http://www.ocadu.ca/>
> www.idrc.ocad.ca <http://www.idrc.ocad.ca/>
> On February 23, 2016 at 1:08:39 PM, Joseph Scheuhammer (clown at alum.mit.edu <mailto:clown at alum.mit.edu>) wrote:
>> Hi Justin,
>> I'm not sure if I understand the issue completely, but it made me think
>> of the new aria graphics roles, specifically, the "graphic-symbol"
>> role. That is used where a small "icon" symbolizes something else; an
>> example would be the symbol for a lightbulb in a circuit diagram.
>> Here's the current proposed spec:
>> http://rawgit.com/w3c/aria/master/aria/graphics.html#graphics-symbol <http://rawgit.com/w3c/aria/master/aria/graphics.html#graphics-symbol>
>> I don't think this is exactly the same idea as that for font icons, but
>> it's close. There are other roles in that document for other kinds of
>> graphics. And, for ARIA 2.0, there are even more, see:
>> http://rawgit.com/w3c/aria/master/aria/graphics2.html#role_definitions <http://rawgit.com/w3c/aria/master/aria/graphics2.html#role_definitions>
>> Take all with a grain of salt in the sense that these are still in the
>> proposal stage and will take time for browser/AT uptake.
>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>> - C. Carter -
>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work