* Karv Prime <karv.pr...@gmail.com> [170914 13:16]:
> 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.

As I said in my previous post, if the <div> element is useful for the
designers, e.g. to position or align the whole replacement summaryData
(which I am assuming is significantly more complicated than some
unformatted text), then by all means put it in.

The point about not needing the <div> tags was really more directed at
use cases where you are inserting some simple replacement in the middle
of the content of a larger element, e.g.

  <p>Hello, {{.Name}}, you last logged in on {{.PrevLogin}}.</p>

Doing this with DOM manipulation requires extra <span> elements around
the items to be replaced.  The snippet above is much easier to read and
maintain than the corresponding HTML with <span> elements, and produces
smaller, more readable HTML to send over the wire.

The <div> tag also _may_ not be needed in cases where the replacement
content is significantly larger, contains multiple elements, and a
container is not needed to separate the replacement from elements before
and after it.

> 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.

No, the main file has

  <main><some-elements />{{.summaryData}}<more-elements /></main>

The program is told where to put it by the designer.

My point was that the designer must use something to identify the
location for the replacement, and there is little difference to the
designer whether the file has

  <div id="summaryData"></div>
or
  <div>{{.summaryData}}</div>

I posit that the second is much easier to recognize as a placeholder for
data that will be supplied later; easier for the designers, easier for
the programmers, easier for outside consultants unfamiliar with the
project, easier for new hires, and easier for management.

...Marvin

-- 
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.

Reply via email to