Why is this a plugin? I'm likely only going to be using one of these types of captions, which I can write in about 5 lines of stylus. The rest of the options that you added to make this a 'real open source project' are then cruft.
EDIT: Sorry, not to denigrate your hard work, but I was burned early in my career by trying to use too many labor saving plugins. Later, I learned how to code correctly. I found that I could accomplish in 30 lines of js and 10 lines of css what I had previously downloaded a 500 line plugin for. I wondered why people found it necessary to build such bloated plugins, and realized that it probably stems from a desire to make a 'real, full-featured project'.
* what the hell is stylus? your favorite tool isn't necessarily ubiquitous.
* it can serve as a learning tool for others. open source, remember? learning, and stuff.
* it could serve as a starting point for a minimal/stripped down version someone hacks away from.
* not everyone cares about 40 vs. 500 lines. some just want a cool and clean effect for a small audience, perhaps a small gallery site for a pro wedding photographer doing her/his own site.
* sorry, not everyone is as awesome as you are at coding. please bear with us while this guy releases hard work for free.
You make a valid point. If a person just needs a quick one-off caption for a single image and they know their way around CSS, then this might not be for them.
I am aiming to build a clean, consistent solution that can be grabbed from bower more quickly than finding similar lines of code in a blog.
Furthermore, I found it to be non-trivial to come up with a solution that didn't require specifying a predetermined image width. I hope captionss saves people that trouble as well.
This is my first legitimate open-source project, I would really appreciate any feedback and suggestions related to the project as well as the landing page (captionss.com).
Good one, looks neat, and congratulations on your first open source project!
Can there be addition where there is one more mode where there is a small icon lets say 'i' at the a specific location (left top, right top, left bottom, right bottom) which when clicked/hovered on brings up the caption or a detailed write up panel?
Looks like some pretty solid CSS with one exception: you are changing font size and colors for the default figure tag. While it's not a common tag, it is used elsewhere. This may cause issues for some users, causing them to have to prefix your selectors.
Yes, in addition to what javajosh found, your class names are rather generic and I imagine might lead to clashes. I'd personally recommend prefixing your class names with something (rather like FontAwesome now prefixes their classnames with 'fa-').
Maybe the figure element is so rare that this doesn't matter, but that is making some sort of an assumption.
Apart from that this looks great, and I could definitely see myself using this in a project I'm working on!
Oh, sorry... one other thing. I just noticed in the README you redirect people to the website for documentation. It's fine to link to the website of course, but I'd recommend putting at least some usage examples in the README itself so people landing there get some idea of what the project is about without having to navigate away (which might turn some people off).
I really wish the pages for projects like these would devote even a small section of their documentation to accessibility. I know it's not usually top of mind, and not everyone is bound by Sec508, but it is an oft-ignored best practice.
I'm not saying this is inaccessible - it looks like it would be okay at least as far as screen readers are concerned, though there may be color contrast issues depending on the image (here's an idea for a cool project - analyze the image and set a color on the caption that meets WCAG AA contrast ratios). It's just every time I see a some cool new css/js wizardry, the only way I can find out whether there's any accessibility compliance is to poke through the rendered markup, test out hover states, etc.
How does this support touch devices? Do they have to tap on the picture to see the caption, or does it show up automatically? I could see that being an issue if clicking on the image also brings up a full-size version of the image.
Looks very pretty, as does the semantic markup. Personally I'd prefer it if there was a little less alpha, e.g. on the Malta pic the text isn't so clear...
I just had a play myself and I like somewhere between 0.8 and 0.85. I'm not a designer though and lean a lot more towards clarity vs style.
When using it I wouldn't want to have to manually pick a theme based on the pic, as it would probably be a database gallery - but a choice of themes is great to have.
It'd help to include at least basic support for some older browsers -- there are still a decent number of users on IE8, for example, but you seem to support only 9+.
It already supports fading in and out with CSS animations. I was thinking of adding slide up/down animations, but am not sure of a good way to implement this.
Use CSS transforms. Unlike absolute positioning, percentages with a transform bases the resulting value off the transformed element's size. So something like this:
Do you think this could be accomplished with just CSS? It seems to me that this would be a stretch for CSS, but I am not extremely well versed in CSS animations.
EDIT: Sorry, not to denigrate your hard work, but I was burned early in my career by trying to use too many labor saving plugins. Later, I learned how to code correctly. I found that I could accomplish in 30 lines of js and 10 lines of css what I had previously downloaded a 500 line plugin for. I wondered why people found it necessary to build such bloated plugins, and realized that it probably stems from a desire to make a 'real, full-featured project'.