Почему web так убог?

Посмотри на input'ы! Сколько надо было выкурить, чтобы придумать отдельные теги для select и textarea, зная что формы будут генериться автоматически?

Ты не видишь разницы между select и textarea? И почему они должны генерироваться?

Сколько надо было выпить чтобы придумать что не чекед чекбокс вообще не будет передаваться?

Зачем передавать лишнюю информацию?

напейся проспись!

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

Не. Потому что бумага - это одно, а дисплей - совсем другое. Бумага не умеет прокрутку и гипертекст и динамику.

Я думаю, да. Но видимо без нескольких итераций нам оно не светит.
Так и живем: отдельно ТеХ, отдельно ПДФ, отдельно ХТМЛ, и везде костыли.
Тьфу.

замену портажу вон уже написали в соседнем форуме, здесь должна родиться замена HTML!

ТеХ никакого отношения к HTML не имеет. Вообще никакого. Это вообще перпендикулярные вещи.

Спасибо, кэп, я именно об этом.

Еще раз - меня не столько смущает, «что text и checkbox называются input, а enum и multi называются select», сколько то что text и radio называются input, а select - select. Тебе никогда не приходило в голову, что radio гораздо ближе к select по смыслу и поведению, чем text от textarea дальше?

Как нужно было подходить к задаче чтобы придумать в css свойство color, но не придумать переменные для его значений?

scss

Зачем передавать лишнюю информацию?

Действительно. Тогда тебе встречный вопрос - почему передается пустой text?

Я знаю. Но это не отвечает на вопрос.

сколько то что text и radio называются input, а select - select.

text и radio это самостоятельные элементы, а select это список.

Действительно. Тогда тебе встречный вопрос - почему передается пустой text?

Потому что пустая строчка это тоже значение которое может нести смысловую нагрузку.

Я знаю. Но это не отвечает на вопрос.

Потому что переменные это элементы программирования, а css это таблицы стилей.

Прикинь, не отмеченный чекбокс тоже может нести смысловую нагрузку.

Но ведь селекторы классов есть, а классы это ничто иное как переменная которая суть элемент программирования, а css это таблица стилей ))) По сути css это набор дефайнов и рекурсивные дефайны ни чего бы не изменили.

Прикинь, не отмеченный чекбокс тоже может нести смысловую нагрузку.

Не несет. В противном случае логику сайта придумывал идиот.

radio это элемент списка. Так что если ты подходишь с этой стороны, то придется объяснить почему option не input.

а классы это ничто иное как переменная

Это идентификатор, указатель... но ни как не переменная.

Прикинь нужно узнать что-то что предполагает ответ Да или Нет. Пользователь ожидает чекбокс, но не идиот придумывающий логику сайта понимает что здесь надо использовать select. Что делать дизайнеру?

radio это элемент списка.

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

Хорошие определение. Почему не может быть вложенных указателей?

Прикинь нужно узнать что-то что предполагает ответ Да или Нет. Пользователь ожидает чекбокс, но не идиот придумывающий логику сайта понимает что здесь надо использовать select.

radio, так что все таки идиот.

Что делать дизайнеру?

С каких пор дизайнер должен вникать в html?

Хорошие определение. Почему не может быть вложенных указателей?

чего?

Но ведь со стороны данных смысл у них остается один - выбор из нескольких возможных вариантов.

Но ведь со стороны данных смысл у них остается один - выбор из нескольких возможных вариантов.

«да или нет» это выбор 1 из 2.

Тебе никогда не приходило в голову, что radio гораздо ближе к select по смыслу и поведению, чем text от textarea дальше?

Вот уже скоро пятнадцать лет, как мне глубоко насрать, почему select называется select, textarea - textarea, и даже почему в языке C нет ключевого слова elsif.

Пусть radio. Дизайнер все-равно рисует чекбокс.

С каких пор дизайнер должен вникать в html?

Опечатка смысла - верстальщик конечно.

Почему ты думаешь что radio это 1 из 2?

scss

Это костыль, вызыванный отсутствием в CSS элементарного даже не языка, а хотя бы препроцессора.

Пусть radio. Дизайнер все-равно рисует чекбокс.

Ну и сделай стиль у radio такой как нарисовали, в чем проблема?

Это костыль, вызыванный отсутствием в CSS элементарного даже не языка, а хотя бы препроцессора.

css - клиент сайд, scss - сервер сайд.

Дизайнер все-равно рисует чекбокс

Ему виднее. Он дизайнер. И для этого проекта у тебя будет расширение генератора, которое будет уметь рисовать этот выбор как чекбокс. В чём бутерброд, ещё раз спрашиваю?

в языке C нет ключевого слова elsif

Да elsif по хорошему и в пэхе не нужен - для этих целей есть swith.

И что? JS тоже клиент-сайд, давай его запретим? Скажем что на клиенте должна быть только декларативность?

Ну и сделай стиль у radio такой как нарисовали, в чем проблема?

Проблема в том, что это уже костыль. А еще большая проблема тебя ожидает, когда ты вспомнишь, что при клике на выбраном radio он не переключается. Так что этого костыля тоже мало - нужен будет еще один костыль на JS.

Я не знаю как в пыхе, а в перле нередко проще написать if - elsif - else, чем колдовать с given. Не всегда, но нередко. Но это уход от темы.

Блин, да как раз в этом генераторе!

Наконец ты признался, что проблема в генераторе, а не в html.

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

И что? JS тоже клиент-сайд, давай его запретим? Скажем что на клиенте должна быть только декларативность?

JS это ЯП для клиент сайда. css это таблицы стилей. scss можно считать как ЯП для генерации css.

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

Я не говорю - логику. Я говорю - препроцессор. Мне сишного препроцессора там за глаза хватит. Потому что специально компилировать чисто клиентскую штуку на сервере - костыль.

идиоты не додумались сделать в html циклы чтобы таблицы рисовать

В xslt додумались. От этого стало только хуже :)

Проблема в том, что это уже костыль.

Какой костыль? В том что дизайнер квадратный radio нарисовал? Так это мягко говоря условное отличие radio от чекбокса.

А еще большая проблема тебя ожидает, когда ты вспомнишь, что при клике на выбраном radio он не переключается.

чего?

Ну вот как раз у меня сейчас такой случай...

Потому что специально компилировать чисто клиентскую штуку на сервере - костыль.

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

то идиоты не додумались сделать в html циклы чтобы таблицы рисовать

Ну насколько я понимаю php как раз есть те самые циклы, только вот ими не ограничилось.

А на клиентах это каждый раз будет компилироваться

А держать в памяти результат «компиляции» клиент не может? С html он как-то справляется, не перерисовывает заново каждый раз при смене вкладки, например.

чего?

Того. Юзер нечаянно тыкнул в radio в виде чекбокса, а теперь хочет снять эту галку. Но radio с ответом Нет скрыт, потому что дизайнер решил там сделать флажок. И?

Это не проблема HTML.