Proper Filter Installation
Published 7 years, 8 months pastI 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?
Comments (6)
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
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.
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);}
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.Yes. In a non-browser-tech-jargon sense of the word, that’s clearly what they are.
One of these is not like the others. (Or else their names would be
png/andwoff/.)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.