dbpatchя тебя просил показать пример grid-а на HTML, с фиксированным заголовком и подвалом, а ты что показал?
в этом примере прекрасно всё, начиная с того, что фиксируешь высоту. что в век адаптивных разрешений выглядит дико странно.

http://jsfiddle.net/meyertee/AH3pE/

dbpatchPL/SQL. Java слишком натужна, а остальное слишком неэнтерпрайзно.

pl/sql как сервер приложений? мдя...

dbpatchКакой смысл это делать? все "верстальщики" норовят это сделать через javascript, т.е. через костыли и зависимости на внешние библиотеки, на чистом html/css сделать никто не может, потому задача с расчетом ширин колонок на клиенте отложена до лучших времен.

в топег призываются свидетели чистого html/css

dbpatchесть правило - совсем не можешь на чистом SQL, бери PL/SQL, только потом Java или C
так и тут

нет такого правила, глупости.

dbpatchесли задача решается на html/css, то js идет в сад

какие-то мантры бестолковые.

dbpatch http://osql.ru/?p=54 При разработке приложений баз данных я использую очень простую мантру:
• если можно, сделай это с помощью одного оператора SQL;
• если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
• если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру
на языке Java;
• если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке С;
• если это нельзя реализовать в виде внешней процедуры на языке С, надо серьез-
но подумать, зачем это вообще делать…

стыдно про это не знать, ой как стыдно, а еще 15 лет на фронтах...

Том Кайт конечно мудрый чувак, но частенько он сыпет советами для дурачков
тем более его творчество упало на то время, когда была массовая истерия, или как модно ща говорить, хайп по поводу логики в СУБД. чуть позже люди начали понимать, что это писец полный, так делать не нужно, и советы эти можно затолкать в утиль.

dbpatchЕго принцип (мантра) универсальны, и вполне перескаются вот с этим правилом: https://habrahabr.ru/post/347166/

«Прежде чем начать, хотелось бы объяснить вам мой подход к разработке. Я предпо-
читаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в
СУБД, я так и сделаю. Для этого есть две причины. Первая и главная состоит в том, что
если встроить функциональность в СУБД, то ее можно будет применять где угодно.»

его мантры это курам на смех, когда пишет по делу, чё там и как в Oracle -- ок
когда начинает рассуждать, как наивный мальчик, это нужно пропускать

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

кто-то путает абстракции с инструментами и технологиями.

dbpatchа html/css они более менее статичны и стандартизированы, обратная совместимость гарантируется, обрабатываются непосредственно C++ машинным кодом,

https://developer.mozilla.org/ru/docs/HTML/HTML5

сегодня html это html/css/js, вместе неразрывно, как одно целое. ушла эпоха отключаемых скриптов пользователями в своих уютненьких операх.


dbpatchтогда как js - это типичный биореактор, с GC на борту, в библиотеках которого не гарантируется преемственность - и не надо ляля, в том-же APEX можно пронаблюдать несколько версий jquery и не только, как говорится, с чего-бы вдруг?

я диву даюсь, какое же богатое у вас воображение. фантазии так и прут )))


dbpatchда, можно писать исключительно на vanilla.js, но... зачем, если для тех или иных вещей (те-же меню, табы) можно вообще без него?

можно, но в академических целях. не в практических.