Shared dependencies about todomvc

[addyosmani]

For the most part, the reason why there is a dedicated stylesheet per implementation (and perhaps dedicated JS libs) is:

• Stylesheet overrides and fixes are required for some implementations due to how they output views (which can greatly differ). One could take the approach of having a base CSS file and then a framework-specific patch stylesheet, but see point 3 below for why I would argue this wouldn't be that valuable.
• Some frameworks are not yet compatible with the latest version of libraries like jQuery, so having a shared folder would not be of great assistance for those. There may however be benefit if most are say, using jQuery 1.7.1 for example.
• Being standalone means that someone can just copy an implementation folder, start experimenting with it and not worry about it being tied to the rest of TodoMVC / having to figure out what other files are needed.

Given that we have a directory structure (for at least the Todo app rewrites) in place which clearly defines where styles, libs etc go, I don't think they're that distracting personally.

@boushley your thoughts?

[boushley]

I was going to say some similar things. A lot of the differences do disappear when we standardize around the same base html, however many of them would still have some small overrides. I think the rewrite that we are performing ( @webpro see the pending pull requests for backbone and vanillajs) will simplify this and avoid much of this distraction.

@webpro You should checkout the template we now have here and see if it addresses any of your concerns. I agree that the current projects have many distractions, however I think that the rewrite we are doing will minimize this confusion without losing the independent nature of each implementation. If you don't agree or feel we've missed your point after looking at the templates and the rewrites we are currently performing please let us know.

[webpro]

@boushley, I don't mean to standardize on a file/folder structure (= template). But really to share CSS/JS across implementations.

• By the nature of git you always clone the whole project anyway
• CSS/JS overrides are fine, they can go in the implementation folder
• The shared folder can also contain multiple versions of any library.

With such a shared folder, a template could be instantly used as well. And for anyone copying a separate implementation (how often does that happen?), needs to copy/change a couple of references. To me, that is much less relevant than the actual purpose of this project: minimize threshold to view, analyze syntax, getting involved. Having only one or two files in an implementation folder sounds nice and tidy to me.

By your answers I hear you probably don't (completely) agree with me. That's fine, I would just do it differently.

In the end this is only a minor issue. It seems more important to me to get the "app.js" right, in terms of implementation, readability and in-line comments.

[sindresorhus]

I actually like this idea, I've had it myself a couple of times, but like @boushley said, some implementation differs too much that overriding the base CSS is feasible. However, I do think we should make it clearer that the new implementations should strive to use the base CSS as much as they can. Even though we are happy with how it looks right now, taste changes or visual bug appear, and right now it's a pita updating every CSS for every little change. Had we done the base and override method, then we could just update the base, and hopefully everything would be fine. Most of the frameworks are GUI agnostic anyway, but there are a few with GUI built in that would be almost impossible to just have override. I think the way forward is to check each new (and existing) framework, and see which can use the base CSS without any modifications, which that needs some overrides, and which that needs to completely mess up the base, and then have a list in the wiki, for further reference. We should make it clear that those frameworks that just needs a few overrides, should put them in a overrides CSS. Btw, just a suggestion. Any thoughts?

Another thought is, instead of bundling every single framework, we could just link to them on a CDN. That would still make the examples standalone, but prevent JS files from beeing duplicated and it's you wouldn't have to change the references.

[webpro]

Well, I don't see any issues to one generic base.css, to which any implementation (GUI framework) can go wild.

Yet imho, the specific look and feel of that GUI is not all too irrelevant here, why not keep it that way. Just make sure it matches the "Todo Application Specification" (which may require some tweaking in this case).

[boushley]

So I guess I'm warming up to the idea. Most of the frameworks would be able to share a majority of the css file. The backbone and vanillajs implementations that I have could share pretty much the entire thing, with two visibility overrides (which I could probably just put into the js code.) This would significantly simplify things since we don't even have to worry about whether the css files are different since it would be very clear whether or not they had overrides/used their own.

@webpro As to your comment about making sure the applications meet the spec and then not worry about the rest, I don't think I agree. I want these examples to be as similar as they possibly can be. I want this both in the look and feel of how they operate (ideally this would be identical) and in the underlying html/css that they use. This will allow users to skip having to grok how each application is achieving its layout since they should all have the same html/css.

This idea is definitely growing on me @addyosmani thoughts?

[webpro]

I want this both in the look and feel of how they operate (ideally this would be identical) and in the underlying html/css that they use.

Mostly agreed, although I can imagine some fancy GUI framework styling a checkbox or an input field, and that would require another overwrite of the base styling. But I think there aren't many that do a lot of styling in the first place.

having to grok how each application is achieving its layout

Eventually, I guess CSS is not so relevant in this project. That's part of the reason I brought this all up. I, for one, would look at the Javascript first, and then maybe at the HTML (I wouldn't care so much for the CSS, expecting it to be the same across implementations).

[addyosmani]

@boushley I'm with you all on us having a base CSS theme that all of the applications use with an override in place for application-specific changes that are needed. It does also make sense to have shared dependencies (e.g jQuery) located in a shared folder with multiple versions depending on framework compatibility.

I wouldn't have anything beyond that in there (we've had mention of JS overrides but that's probably a little on the extreme end) :). @sindresorhus do you think you might have time to experiment with a base theme file?

[sindresorhus]

@addyosmani The app.css is pretty generic, so I don't know anything else to do with it than to rename it to base.css and move it to the shared folder together with the JS libs. And then leave the app.css empty with a comment that it should be used for overrides.

We have a couple of options on how we want to reference the files:

• Relative path (../shared/base.css) to the base.css and JS libs. This will make it harder to just copy a frameworks folder out of the TodoMVC folder and start hacking on it.
• Absolute path to master on GitHub, (our personal CDN :P). This will make every frameworks folder portable, but will introduce some inconsistencies if we update the base.css with something that depend on html changes in master, since they will only get the updated CSS locally. Same with JS libs. Example path: https://raw.github.com/addyosmani/todomvc/master/shared/base.css.

Thoughts? Any better way to do it?

[addyosmani]

@sindresorhus Good question!

I would be okay with the relative path option personally. If we're opting to go down the route of having a base CSS file we'll be breaking the ability for someone to just copy/paste folders and start using them for other projects anyway. The CDN option isn't a bad one, but I think we need to keep in mind people will want to be able to use projects from time to time without any dependencies that are external / require a connection.

@boushley your thoughts?

[sindresorhus]

This had been fixed. Updated app spec and template (#100).