Собственно вопрос.

Нужно получить нечто вроде, т.е. классическую-каноническую экранную форму.



но чтоб единообразно и хорошо работало под IE11, Chrome, FF, etc: мы указываем в html только label, inputs, а оно само,
считает нужную ширину колонки с label и соотсвественно оступает колонку с inputs, ну и само собой labels, inputs на одном baseline


Попытки заиспользовать grid-layout закончились пшиком, даже Example 24 из https://drafts.csswg.org/css-grid-1/
работает толком только в Chrome, и в целом ситуация с display:grid похоже печальная на еще N лет вперед.

На коленке удалось запилить через самый обычный <table><tr><td><label ..></td><td><input...> </td></tr>
но сразу сомнения, потому что аккуратно впилить <fieldset> не получается (только если его представлять как отдельнй вид <tr>).

Ну и в целом - tables are bad (хотя непонятно почему bad, действительно, почему?)

Поиграться с display:table тоже не сильно получилось - там и вовсе расползается колонка с inputs и опять-же не решается fieldset,
да и по сути это тот-же <table>, только на <div>, чем оно теперь лучше, чем просто <table> не понятно, реально, почему это уже не tables are bad?


Вопрос - как можно красиво и без тонны всякой bootstrap/vue/react ерунды и прочих polyfill/mixin костылей в современных браузерах сделать html формочки?

Лично я бы остался на <table>, если бы не <fieldset>

hVosttdbpatch,

любая CSS Grid библиотека решает твою задачу прям в лоб, например на Bootstrap такая форма делается прям по сетке и получается очень даже приемлимый результат.

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

а я не хочу их поделки, из нужно сопровождать и поддерживать (обновлять), не говоря уже об изучении и багфиксах.
при том, что через три года оно окончательно загниет.

спасибо, плавали.

тем боее, эти "ребята" решают обычно "задачи" вроде поддержки IE6, IE9, мне это не интересно, у меня ограничение edge версиями браузеров.

частично магия достижима, вот первый ответ
https://stackoverflow.com/questions/9325426/css-how-to-create-a-label-width-of-the-longest-containing-text

но его решение не покрывает элемент Department выше, ну и в разных fieldset отступы будут разные, мне это не сильно подходит - на Department я бы еще забил, но вот разные отступы в fieldset - нет.

в целом все это как-то странно, уже 23 года прошло, а никак даже обычные forms на html запилить не могут. чем эти ребята из w3c вообще занимаются?

skyANAdbpatchВопрос - как можно красиво и без тонны всякой bootstrap/vue/react ерунды и прочих polyfill/mixin костылей в современных браузерах сделать html формочки?
Раскурить HTML5 semantic elements и сделать.

ты уже раскрурил и сделал? пример покажешь?

hVosttdbpatchЛично я бы остался на <table>, если бы не <fieldset>

flex не пробовал посмотреть?

пробовал, он разве решает проблемы колонок?

все примеры, из просмотренных, напирают на то, чтоб я константой вбивал ширину labels, я такое и без всяких flexbox-ов могу сделать на обычных блоках

вадяdbpatch,

https://habrahabr.ru/company/microsoft/blog/140715/
https://habrahabr.ru/post/325760/
https://habrahabr.ru/company/nixsolutions/blog/326098/
https://habrahabr.ru/company/edison/blog/343796/

Зачем это? это не работает с IE11, от которого по определению отказаться нельзя - в корпоративе он будет жить еще лет 10.

hVosttdbpatchа я не хочу их поделки, из нужно сопровождать и поддерживать (обновлять), не говоря уже об изучении и багфиксах.
при том, что через три года оно окончательно загниет.

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

так что рассказывать сказки не нужно :)

https://jsfiddle.net/251ue64h/

интригующе, но спорно.

я сделал первую метку "First name name name" и растянул форму на 1920px. Вместо того, чтоб расположить все одну строку, он сделал перенос.

Фонарь-с...

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

вадяdbpatchЗачем это? это не работает с IE11,
не совсем
https://caniuse.com/#search=CSS Grid
может что-то сработает.

то, что работает - ничем не отличается от обычного <table> или display:table, мотивации это "заюзать" - ноль целых ноль десятых

hVosttdbpatchпробовал, он разве решает проблемы колонок?

все примеры, из просмотренных, напирают на то, чтоб я константой вбивал ширину labels, я такое и без всяких flexbox-ов могу сделать на обычных блоках

вообще-то, ты должен вбивать ширину лабелс. тебе за резиновые лабелс в горизонтальных формах любой UX-дизайнер оторвёт руки по самую шею.

хотя, если программист взялся делать дизайн, катастрофу уже никто не остановит

у меня нет задачи "дизайна". у меня кодогенератор форм от базы данных, что-то вроде Oracle Apex, для сугубо внутренних задач, там невиданные лебедевые красоты не нужны.

считать фиксированно ширину меток - да, это похоже и придется делать.

в конце концов это уже приходится делать, чтоб сделать fixed-header, fixed-footer таблицы, там тоже - иначе никак, кроме как на server-side считать em-ки с запасом 20% чтоб не "налезало", но признаться я не думал, что и в области форм все настолько печально в этом вашем html.

hVosttразработчики взаимозаменяемы. кастомизируется, тысячи решений и ответов на stacjoverflow. как можно этим пренебрегать?

да, есть и такое, бутстрап головного мозга. надо знать меру )
то-же самое говорили и про jQuery, дескать как этим можно пренебрегать?

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

т.е. в случае "протухания" меняем только собственную библиотеку, и все работает :)

но в контексте текущей задачи - вариант посчитать на сервере (в библиотеке) ширину label в em-ках с запасом - мне кажется куда меньшим злом, чем донавешивание еще и boostrap в зависимости

hVosttdbpatchу меня нет задачи "дизайна". у меня кодогенератор форм от базы данных, что-то вроде Oracle Apex, для сугубо внутренних задач, там невиданные лебедевые красоты не нужны.

и что это меняет для пользователей?

Это меняет для разработчиков. Тут нет задачи ваять сайт именно как сайты для public сектора.
Скорее задача сделать что-то вроде 1С (Oracle Forms, Oracle APEX) с веб браузром для UI.

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

Т.е. есть формочка для ввода единицы оборудования - вот набор полей, их типы (просто текст, LOV, дата), сколько примерно символов должно вмещать, порядок (первое-второе-третье), а как их покажет браузер - уже не важно, т.е. разработчик об этом думать не должен.


hVosttdbpatchсчитать фиксированно ширину меток - да, это похоже и придется делать.
можно сделать её адаптивной, как это сделано в bootstrap. также ограниченно адаптивно резиновыми они тоже быть могут.
ну, мне проще - адаптивная разметка на самом деле не нужна, мониторы у всех пользователей типовые - 1920x1080(1200),
для планшетов UI в основном не нужен, кроме пары-тройки спецтализированных форм (вроде инветаризации).


hVosttdbpatchв конце концов это уже приходится делать, чтоб сделать fixed-header, fixed-footer таблицы, там тоже - иначе никак, кроме как на server-side считать em-ки с запасом 20% чтоб не "налезало", но признаться я не думал, что и в области форм все настолько печально в этом вашем html.вот здесь, признаться, ничего не понял

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

Т.е. нужно получить что-то вроде этого:




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

Как решение - делаем три html таблицы, для header, rows, footer. rows живет в своем контейнере с overflow-y: auto, header и footer заданы через position:relative, и все это вместе - в своем контейнере с overflow-x: auto

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

skyANAdbpatchу меня нет задачи "дизайна". у меня кодогенератор форм от базы данных, что-то вроде Oracle Apex, для сугубо внутренних задач, там невиданные лебедевые красоты не нужны
То вариант взять готовую либу, чтобы не тратить время и деньги на разработку своей, имеет право на жизнь.

Вот если бы стояла задача спроектировать (задизайнить) свой набор компонентов с определённым поведением, то да...

Веб это не Delphi, где написал раз, а потом просто перекомпилируешь и все работает как и раньше.
Уже был печальный опыт, когда новый браузер разрушает цивилизацию, а обновление всех внешних зависимостей вызывает системный кризис (и мы вынуждены жить на IE7 вечно).

Но даже это не суть проблемы.

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

Есть желание избавить его от этого веселого занятия, оставив в доступности очень ограниченную семантическую модель (API) для UI.

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

Ой да ладно. Пусти веб разработчика в десктор, он проблюётся раз сто, и скажет, что такой жести он ещё никогда не видал, а на вебе вот это и это делается долбаным стилем за 10 сек.

Просто проблемы перехода ))
Это пройдёт.

Еще раз - нет задачи именно веб разработки. Есть задача сделать минимально достаточный UI для ввода данных в БД (на самом деле там не только и не сколько БД, но это не суть).

Я же говорил - тру лебедевиные дизайны не нужны.

А так да, десктоп UI сейчас стагнирует, кроссплатформы там не было и не намечается в обозримой перспективе, потому и взяли веб на вооружение - там вся кроссплатформа "бесплатна". Ну, есть свои конечно приколы с несовместимостями браузерами, но они локализируются очень малой кровью, в сравнении с.

Petro123 непонятно..
Вы делаете копию апекс?
Да, по мотивам. APEX на текущей стадии это, ИМХО, тупик.
Потому что version control там не решен и решен похоже не может - достаточно глянуть, ЧТО он экспортирует в текстовый дамп, чтоб отбросить идею о code review как класс. Впрочем, этим страдают все IDE с кодогенератором, без исключения.

Хотя в целом идея APEX, как средство избавить разработчика от HTML/CSS/JS знаний - очень оок.

Petro123 И почему скрин десктоп для веб?

Это просто пример того, что нужно получить - понятие фиксированный заголовк и фиксированный подвал в таблице.
Делать скриншоты из веба.... на наверное extjs такое может, мне лень было искать: http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#paging-grid

Petro123dbpatchЕсть задачалибо Apex бесплатно. Либо проф. Верстальщик в штат. Это же очевидно.

оба варианта отпадают по причине связанных затрат на сопровождение и бесперспективность в среднесрочной перспективе.

hVostt что знаю о чём говорю?
Ок, скажи адрес, тебе пришлют медаль "15 лет веб победы"


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

Т.е. есть формочка для ввода единицы оборудования - вот набор полей, их типы (просто текст, LOV, дата), сколько примерно символов должно вмещать, порядок (первое-второе-третье), а как их покажет браузер - уже не важно, т.е. разработчик об этом думать не должен.

Всё верно! Разработчик, программирующий ДОМЕН, не должен думать о формочка. Но разработчик, делающий генератор форм должен подумать раз эдак в пять по-больше разработчика, который верстает уникальную форму по образцу, так как как надо учитывать охрененное количество вариантов и ньюансов.
Не пойму, о чем ты вообще говоришь. Чтоб разработчику сделать типовую форму Заказ (наименование, количество, цена, сумма итого), ИМХО, особо думать не надоть.
Описал декларативно форму Документ как набор Полей, описал подчиненную таблицу Строки, аналогично....
Т.е. только свойства задать.... Все.

Если, конечно, ты не веб разработчик :)

Попрограммировать там можно только валидации какие.

hVosttАга, теперь понял. На HTML/CSS делается элементарно.
Да неужели? Пример покажешь?


hVosttdbpatchВ вебе по дефолту скроллируется всё

Ничё не всё. Фиксируешь свой <div>, задаешь его размеры по высоте, добавляешь в стилях скролл и получаешь результат. В HTML это делается разы проще, чем в десктоп.
Я сказал - по дефолту. А в десктопе скроллирование даже описывать не надо, оно где надо уже даром поставляется в компонентах гридов, о чем ты?


hVosttdbpatchКак решение - делаем три html таблицы, для header, rows, footer. rows живет в своем контейнере с overflow-y: auto, header и footer заданы через position:relative, и все это вместе - в своем контейнере с overflow-x: auto
Ну так себе решение. Может потом таки уйдёшь от таблиц, когда сам допетришь почему это bad ))
Ок, покажешь, как сделать типовой grid с fixed-header, fixed-footer на DIV-ах?


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

Работать будет. Но таблицы это в первую очередь не адаптивно. Да-да, я знаю, в корпоративном секторе легко можно залупиться и тыкнуть в морду требованиями. Но, жизнь сложнее чуток.
В смысле не адаптивно? Тебе никто не мешает точно таким-же образом, через @media задавать предопределенно ширины колонок для каждого разрешения. Для FullHD однострочные таблицы, для каких планшетов - с вариантом текст в ячейке две строки, чтоб все в экран влезло по ширине, хотя за такое нужно, наверное, руки в двери.

В общем неадаптивность табличного отображения данных - тема не раскрыта, куда там что адаптировать?

Petro123dbpatchпропущено...


оба варианта отпадают по причине связанных затрат на сопровождение и бесперспективность в среднесрочной перспективе.
Ок. Свитчуйтесь сами в верстальщика.
Апекс очень достойный продукт. У меня был проект. Работает годами у заказчика федерала.

Я не спорю, что очень достойный. Но как я говорил выше - в нем все очень ООК, кроме source code version control.

Если заказчик один и существует только две версии - в проде и в разработке, и для деплоя разрешается лишь покликать мышкой, то APEX - ваше все

Petro123dbpatchЕсли заказчик один и существует только две версии
Нет логики. У вас куча вариантов, но нет денег на программиста.
Впрочем, оффтоп. Удачи!

почему нет? есть. просто нет задачи делать бег на месте, т.е. инвестировать в то, что через три года станет безнадежно deprecated

Petro123dbpatchбезнадежно deprecatedя о верстальщике для генератора.

а смысл? ну "наверстает" он за пару недель мегабайты "своего кода и зависимостей" для пары типовых форм, так, как он привык это делать всегда, красота, во всех браузерах все резинится и плавает, глаз не нарадуется.

а потом открываешь папку, и видишь там сразу 100500 css/js/ts/less/sass, которые он вкопипастил с предыдущего проекта, и что я буду с этим делать?

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

В общем неадаптивность табличного отображения данных - тема не раскрыта, куда там что адаптировать?

Ты похоже не понимаешь, что адаптивность, это не ширины колонок для каждого разрешения.

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





давай лучше про фиксторованные заголовки. начать можно вот отсюда:
http://www.sql.ru/forum/1162633/tablica-fiksirovannyy-zagolovok-stolbec?mid=17822310#17822310


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

Petro123dbpatchзадача отделить прикладную разработку от веб разработки. какой ЯП у прикладной?

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