card templating scheme

[scd]

I have been thinking that it maybe worthwhile considering a ground up approach to our templating scheme, putting in place everything we have learned over the years. While this may not be a big revelation as we have been doing a lot of things in a piecemeal sense. I would like to put it all together using our own design standards, with the luxuary of defining our ideal system and working toward this. I am pretty sure that this is all stuff @brendanheywood has been working toward anyway, and it is just taking me a long time to get a handle of it.

The motivating factor for this is that maybe we can do this for our app work, javascript & css might be portable between the website and app.

At the moment I am just logging this issue as a discussion point, but could easily get very excited about it if it looks like.

Here is a quick brain dump

• [x] theCrag objects should have their own card templates under a standard naming convention (eg card-climber, card-node, card-route, card-area, card-photo for various cards and list-climber, list-node, etc.
• [ ] each card should have css, javascript, events and data requirements.
• [ ] we have already started to build the framework for the css mixins which will support this and I think we plan to do something similar for javascript. Data requirements are already built into the template, however we could be more rigerous on the way we approach this.
• [x] objects should be externally referable and return in various modes so we can get just data, or html for embedding. I think we are mostly on top of this, but need to make sure all objects adhear. Has implications for stream events
• [ ] we should have extensive documentation and examples
• [x] flexible css support for emedding so that our class names do not interact with external sites class names. This means for example the generic btn class is no good when emedding, because it may clash with an external site. Instead we should prefix all our classes with 'tc-', eg tc-btn. This should also be configurable as an argument.
• [ ] we need to fix z-index properly
• [ ] we should define and document standard events and abstract (c.f. as @brendanheywood has done for node.select) so we avoid the touchscreen issues in the future.
• [x] multi language support in the templates. Any text in the template should not be hard coded but rather have a lookup so that we can use other language libraries.
• [x] we have got unique ids between object types which could simplify the underlying design.

Interestingly most of the site is either a card or a list.

This is not meant to be a detailed specification, but rather just initiating discussion before we embark on code for the app.

[brendanheywood]

+10

• css class names should be irrelevant. Either we embed externally in an iframe as we have been or later using new html5 stuff which isolates this
• zindex is easier if you have a global less files for all the layers and never use any numbers directly. See boostrap/less/variables.less line 122 for an example to copy as needed. I have started this on line 46 in portal but it needs a lot of refactoring from all over the place and then we can start juggling layers numbers to make sure they are all correct. We may need to spread the bootstrap ones apart so we can put ours in between if needed. And also need to play nice with zindex used in other 3rd party stuff like openlayers. I found this pretty useful: http://www.smashingmagazine.com/2009/09/the-z-index-css-property-a-comprehensive-look/
• also note that jquery has a specific format and meaning for their event namespaces which I messed up originally and need to fix at some point.
• One semi related thing to the whole cards concept is deprecating poshytip and getting rid of all the big chunks of data mushed into titles and then load it on demand as a hover card. This is especially for hovering over an avatar but is same same for crags or whatever

[leomao10]

Hey @scd @brendanheywood,

I am just throwing some ideas here.

• As the plan is to refactoring the current css, javascript, make it mobile responsive and then make it work in mobile apps. It could be a good idea to introduce javascript frameworks. Currently, there are two js framework that can build mobile application:
  • Angular.js + Ionic
  • react.js + react native

• For @scd 's thought:

  each card should have css, javascript, events and data requirements.

  This sounds like component, which supported by both Angular and react, just react.js doesn't really allow dev to modular css for component, and angular 2 make modular css easier

Just curious, does theCrag use LESS or SCSS to precompile the css?

[brendanheywood]

Less, each component has it's own less file, sorta semi adopted something halfway between OOCSS and BEM . If we can re-use some css in any app then thats ok, but I'm pragmatic around whether this is really worth it. I'm not super keen on rendering the web GUI via js, this generally ends up being bloated and slow. Doing it server side has appeal generally but I think would be too epic to retrofit into our current architecture.

fyi I'm leaning toward using https://www.nativescript.org/ for the app and the intention is to get a prototype working with that as a proof of concept

[leomao10]

:+1: for using Less and OOCSS :D If we carefully craft the css and make it portable with multiple viewport, then I think many of the css can be reused.

I just view the introduction, but the goal nativescript tried to achieve is quite interesting. If that really work, it will save lots of development time to maintain applications in two platforms.

Cheers

Leo Liang

[brendanheywood]

Closing this, we are well down this track already