Это полная жопа, конечно, а не программирование и теперь уже автор положивший столько сил на эту задницу никогда не решится переделать нормально. Нормально, по самому простому, делается примерно так:

var CalcBanner=function(opts){

   var bframe_sel = document.getElementById("ban_frame_id"),

   /* все остальное по тексту */

   /* Теперь надо вернуть что-то важное для взаимодействия функций */
  return {
    foo:foo,
    bar:bar,
    baz:function(){return baz}
   };
};

Теперь все такие функции можно спокойно положить в кучу и подключать через шаблон на всех страницах.

Каждая из которых заканчивается командой запустить ту или иную

<script>calcbanner=CalcBanner({foo:bar,baz:975}) </script>
</body>
</html>

Взаимодействие между модулями могут осуществлять либо сами модули, либо модуль типа контроллера. Который если есть, может запускаться самостоятельно и смотря по адресу или там еще по каким-то признакам - запускать нужные модули и связывать модули и все такое.

На словах пишется страшно, на деле в парадигме js - все очень просто. Это мля не php, тут вообще лафа с такими вещами,

Если функция короткозамкнутая, то есть ничего не возвращает никому, а только развешивает свои приватные методы по событиям на элементах документа, ее можно запустить сразу в конце хтмля или по событию загрузки документа. Например в конце хтмля

(function(){

   var bframe_sel = document.getElementById("ban_frame_id"),

   /* все остальное по тексту */
})();

Из такой функции можно вернуть в window какие-то глобальные переменные если прямо внутри нее присвоить явным образом window[foo]=1060; Или такая функция может работать как тот самый контроллер по событиям на которые она навешала своих методов.

Это микроскопическая толика вариантов, js максимально аморфный и у каждого программиста для той или иной задачи есть свой стиль и свои решения.

Профессиональный программист сразу начнет строить фабрику, выпускать фреймворк, в который втыкать данные, контролировать модели и рендеры (вьюхи). Но с простыми и небольшими проектами можно обойтись простым взаимным взаимодействием или с микроскопическим контроллером.

По простому делается еще проще. Для каждой страницы есть свой специфический код, так? И каждая страница может юзать нечто общее как минимум для двух страниц, или заведомо общее, даже если пока что заюзано только на одной. Надо уметь обощать и сегрегирвать. Отделять мух от котлет в общем. Собрав в кучу все общие места, вы подключаете такой файл на всех страницах, одновременно подключая на каждой ту часть кода, которая ей именно нужна.

Это просто проще некуда.

Посмотрите как устроена страница гугля изнутри. Кто-нить после изучения внутренностей сайта дизайн.ру - гуглю под юбку заглядывал?

То есть страница на которой ровно 1 поле поиска - именно ее посмотрите.

Там стиль, скрипт, стиль, чуть-чуть хтмля, скрипт, стиль, скрипт, стиль, чуть-чуть хтмля, скрипт, стиль, конец страницы.

Я бле заколебывался с этим подключением файлов и особенно кешированием стилей, изучал способны перечислить что надо подключать, потом написать скрипт чтоб выдал по списку свежак в мини-формате (ну то есть по параметрам в запросе) - есть такие приемы. Но однажды захотелось мне упереть с гугля шеврон в бейс64. Открыл их исходник и снизошло мля откровение - вот как надо все делать. Самая мякотка что хтмл для того и существует, чтоб в него пихать все подряд. Я начал пихать и сразу стало гораздо лечге.

Забейте нах на все эти линк рел и скрипт срц - врубайте все прямо в боди там где оно именно надо и именно то, что надо и никаких проблем такого рода не будет.

Или вы думаете зафигом придумали атрибут scoped ?

Действительно, проще некуда:)
Спасибо за советы, прислушаюсь.
Проблему с некорректной работой калькулятор понял)
Думал яваскрипт просто читается по функциям, и что нужно используется, не смотря на то, какие элементы присутствуют или отсутствуют. Поэтому и не сразу понял какое отношение имеет отсутствующий "bsize_sel = document.getElementById("ban_size_id")".
:thanks:

Думаю так и надо поступить, меня сбило то, что все мной просмотренные примеры(большинство) по калькуляторам на сайтах (скрипты) лежали в отдельных файлах:)

Вы пишите скрипт как скрипт, как напишет нормальный человек какой-то активный сценарий. Так можно, но именно так можно когда скрипт у вас прямо в хтмле и сразу после того хтмля, с которым он связан. Собственно так все и начиналось, потом уже начали писать библиотеки и пихать их в срц.

Единственная проблема в этом - ваш хтмл должен быть безупречен. Достаточно пропустить где-нибудь " и парсер наедет на тег <script> всей своей мощью и такого там накомпилирует, что уссышься.

Это зависит от технологии. Если вы вручную собираете хтмл и ресурсы типа стилей и скриптов, то, конечно, в стопицот раз проще будет складывать все в большие файлы и врубать один раз на все случаи, иначе чтобы поправить скрипт или стиль вам придется править хтмл (шаблон например).

Если же хтмл делается скриптом на php, то и все остальные ресурсы php туда засунет как миленький из тех самых _отдельных_ файлов. Щас покажу

<style><?php $this->assets('css','catalog_promo.css');?></style>
<div class="promo">
<div class="promo-m"><?php echo join($items);?></div>
<div class="promo-o" t="Открыть"></div>
<div class="promo-b"><?php echo join($dots);?></div>
<div class="promo-bn"><i class="fa fa-chev-d"></i></div>
<div class="promo-bp"><i class="fa fa-chev-u"></i></div>
</div>
<script><?php $this->assets('js','catalog_promo.js');?>Promo();</script>

У меня средне-классовый недо-фрейморк, легчайший по самое нехочу, поэтому ресурсы подключаются по разумению, по месту, а не из жирных конфигов или пропертей класса модели. В то же время любой класс может профтыкать в стек стилей или скриптов что ему потребуется на рендере. То есть система двояковогнутая.

Как видите сначала идут стили, потом хтмл и сразу же после него - скрипт и сразу же он запускается. Можно запустить автоматически, но я уже забыл почему так осталось - по имени. Работает и х с ним.

Паттерн - стиль-хтмл-скрипт - самый оптимальный. Загрузив стили браузеру вы сокращаете итерации - получив хтмл браза уже знает как что рендерить. Ну а скрипт и должен быть после, чтобы все, что он начнет щупать - уже было в DOM'е

Метод $this->assets() - обычный загрузчик кеша с фичей минимизации текста. Открыл файл, сравнил даты, если исходник свежее - минимизировал, записал и выдал в буфер текст. По опции может возвращать текст - что важно для рендера объектов через __toString();

Кстати вот

t="Открыть"

а в css

promo-o:before{
   content:attr(t);
}

Как видите атрибут может быть любым.

Про атрибуты.

Разница лишь в том, что есть список кошерных атрибутов, которые браузер компилирует в модели документа и рендерит часть кошерных согласно спецификации или близко к ней. Например атрибут disabled вызывает явное засерение кнопки.

Все трефовые атрибуты, то есть которые браузер нипонял - никуда не деваются, они общедоступны через стандартный метод getAttribute(name); Если указанного имени нет, вернется null, или "", не помню, от браузера еще зависит.

Что-то я о подобном не слышал. В jQuery есть метод data(), который умеет читать и писать данные в атрибуте data-, но чтобы в любые "не занятые" атрибуты, это не. Конечно быдлокодер может придумать свой атрибут, например s и записать туда всё что угодно, но тут уже не в библиотеке дело.