meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Proper Filter Installation

I ran into an interesting conceptual dilemma yesterday while I was building a test page for the filter property.  In a way, it reminded me a bit of Dan Cederholm’s classic SimpleQuizzes, even though it’s not about HTML.

First, a bit of background.  When I set up test suites, directories of example files, or even browser-based figures for a book, I tend to follow a pattern of having all the HTML (or, rarely, XML) files in a single directory.  Inside that directory, I’ll have subdirectories containing the style sheets, images, fonts, and so on.  I tend to call these c/, i/, and f/, but imagine they’re called css/, images/, and fonts/ if that helps.  The names aren’t particularly important—it’s the organizational structure that matters here.

So, with that groundwork in place, here’s what happened: I wrote some SVG filters, and put them into an SVG file for referencing via the url(filters.svg#fragment) filter function pattern.  So I had this SVG file that didn’t actually visually render anything; it was just a collection of filters to be applied via CSS.

I clicked-and-held the mouse button, preparing to drag the file into a subdirectory…and suddenly stopped.  Where should I put it?  css/, or images/?  It clearly wasn’t CSS.  Even if I were to rename css/ to styles/, are filter definitions really styles?  I’m not sure they are.  But then, what is an image that has no visual output?

(Insert “one hand clapping” reference here.)

Sure, I could set up an svg/ subdirectory, but then I’d just end up with SVG images (as in, SVGs that actually have visual output) mingled in with the filter-file… and furthermore, segregated from all the other images, the PNGs and JPGs still hanging out in images/.  That seems weird.

I could establish a filters/ subdirectory, but that seems like overkill when I only planned to have a single file containing all the filters; and besides, I’m not in the habit of creating subdirectories that relate to only a single HTML file.

I could dodge the whole question by establishing a generic assets/ subdirectory, although I’ve long been of the opinion assets/, when it isn’t used to toss in all of your assets classes in their own subdirectories, is just a fancy alias for misc/.  And I dislike tossing stuff into misc/, the messy kitchen junk drawer of any project.

I came to a decision in the end, but I’m not going to tell you what it was, because I’m curious: what would you do in that situation?

Six Responses»

    • #1
    • Comment
    • Wed 22 Feb 2017
    • 1211
    Ren Walker wrote in to say...

    I have two image folders generally in my project. First, images/ (or uploads/) in the root contain assets directly related to the content of the page, often uploaded via the CMS. Second, img/ is a folder with assets referenced by CSS. The idea is that my lib items are generally independent of the content and context of the project, enabling me to more easily duplicate or migrate it to a new project.

    SVG filters would thus go within the img folder.

    I will admit, favicons and the logo are a bit tricky; I generally use generic, semantic file names and replace them at the start of a new project.

    Here’s a look at how our team structures our files. Great thing is that for the past 50+ sites we’ve done, I can quickly predict where a file will be on any one of them.

    lib
    |
    |– styles/
    | |– css
    | |– sass
    | | |– base
    | | |– components
    | | |– layout
    | | |– pages
    | | |– skin
    | | |– vendor
    | | |– _screen.scss
    |– img
    | |– favicons
    | |– logo
    | |– etc…
    |– fonts
    |– js
    | |– foundation
    | |– vendor
    | |– etc…
    | |– global.js
    uploads
    |– images
    |– docs

    • #2
    • Comment
    • Wed 22 Feb 2017
    • 1222
    Ahmad Alfy wrote in to say...

    I believe this belongs to the style directory because it is gonna be used exclusively for styling. It is not an *actual* image. The extension doesn’t matter IMHO.

    • #3
    • Comment
    • Wed 22 Feb 2017
    • 1256
    Eric Likness wrote in to say...

    It’s looking like you chose to use the c/ folder in the example URL. I would choose that too. It seems like a filter is like a style. There is a base thing that has something applied to it. It may not be a “thing” in the box model, but still it’s being applied. I say filter = style.

    .li11 > img {filter: url(c/filter.svg#Turb0);}

    • #4
    • Comment
    • Thu 23 Feb 2017
    • 0230
    Jonas Päckos wrote in to say...

    I usually keep a css/gfx/ folder in my projects, where I put css sprites and other stuff that’s called in by css. That’s where I used to put pie.htc and border-radius.htc ages ago, (remember?), so I would probably put a filter.svg there.

    Also, keeping that folder inside the css/ makes it easy to reference from within css files, no need for traversing back in the folder structure.

    • #5
    • Comment
    • Thu 23 Feb 2017
    • 0714
    Aristotle Pagaltzis wrote in to say...

    Are filter definitions really styles?

    Yes. In a non-browser-tech-jargon sense of the word, that’s clearly what they are.

    They’re called css/, images/, and fonts/

    One of these is not like the others. (Or else their names would be png/ and woff/.)

    • #6
    • Comment
    • Thu 2 Mar 2017
    • 1631
    Aaron Gustafson wrote in to say...

    Like a few of the respondents, I’ve often used a /c/i directory for CSS-related graphics items (sprites, icons, and other non-content images). I think I’d probably tuck it there.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


February 2017
SMTWTFS
January March
 1234
567891011
12131415161718
19202122232425
262728  

Sidestep

Feeds

Extras