@Andy Balholm: Perfect. I've seen some other template engines where that didn't happen at all and the artifacts stayed.
@Marvin Renich: Yet tags, classes and ids are HTML standard syntax and used for styling and scripting purposes. {{[...]}} is only a placeholder. It makes no difference per se, that's true. One can also replace "<!-- summaryData -->", "[summary.Data]", "(\summaryData/)" or anything else with the needed input. One could also see the whole "<div class="summaraData"></div>" as a placeholder and replace it accordingly (problematic as soon as spaces and newlines are involved ^^). I wouldn't agree on "there is not even a need for the <div> wrapper" part. If the HTML tags are produced entirely by code, it comes with its own issues - suddenly there is a thing that wasn't in the markup - it would probably reduce maintainability. If there's already a file with <div class="summaryData">[...]</div> it can be reused as the designer sees fit. Let's, for example, assume 2 cases. Case 1: Main file has '[...]<main></main>[...]', the module is the aforementioned div with summary data. The coder has to know where to put it. Does it belong directly in main? Is it inside another element? The backend dev doesn't know without input from the frontend devs - so backend devs are involved deeper into the frontend design as they should be. Case 2: Main file has '[...]<main><div class="summaryData"></div><div class="anotherDiv"></div></main>', the module only has the '[...]' content of the div. The coder doesn't need to know where to put it. Push it around in the frontend, no one has to care about it. One could also put the information which file belongs to the class/id/tag into a database, so the frontend devs can do that all by themselves and no coder is needed. ID: 1, Path: 'modules', File: 'summarydata.html', type: 'class', name: 'summaryData'. Finished. If the wrapper element is necessary or not... usually it should be in most of these cases as newer data can be loaded via script or at least the element is styled/positioned in a certain way. That approach should be done with standalone-modules only. If there's a page with i.E. contact information, one shouldn't put everything inside a certain div and create a div-soup - I would even say that this is most certainly static data as companies don't move around that often (yet for a CMS it should be in the database, sure) - it really depends on the case, but I wouldn't overdo it for the main parts of the page. User provided content is a different story though. But, as you've said, no difference if it's a class/id/tag or a template placeholder. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.