веб, ASP, начало

[come-on]

Чем проще?

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

А если мышкой кликать, то оно любит выставлять размеры

там же в дизайнере поменять высоты/ширины плевое дело.

+ могу еще рассказать, допустим надо половине контролам на окне выставить одинаковый маржинг, руками опять таки заматаетесь, дизайнер - покликал, указал в свойствах, профит.
Еще вопросы есть? то что вы не умеете или не понимаете не говорит о том что это плохо, просто вам надо поучиться. ))

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

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

[OmegaBerkut]

А вот вам пример "одаптивнаго" сайта
Без увеличения - скрин
С увеличением - скрин

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

[Alex11223]

Что-то не понял пример.
Зачем увеличивать? Там ж и так все нормально на мобильных устройствах.

И это вообще рекламный блок призывающий поставить приложение, а не панель навигации. После закрытия не появляется.

[OmegaBerkut]

Alex11223
Это всё равно "некрасиво". Ибо рядовой пользователь может не знать, что означает крестик рядом с этой панелью (действительно может не знать), и жаловаться, что эта панель ему мешает. А увеличивать для того, что бы прицелиться в ссылку, например, или более точно выделять текст.
Что касается "рекламного блока" - это уже не важно. Я встречал такие сайты несколько раз, где из-за не убирающейся панели (навигации, рекламы, и так далее) работать через мобилу просто невозможно. А всё потому что "сайт адаптивный".

[Alex11223]

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

[Naive]

Сообщение от Alex11223

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

+, это косяк конкретных разработчиков, а не методологии в целом.
Если ты увидишь проект недалекого второкурсника по шахматам на ООП, ты же не скажешь, что ООП нежизнеспособно "потому что ..."?
Есть проблема, что веб имеет довольно низкий порог вхождения в отрасль. Отсюда и всплывают на поверхность сайтоделы, которые не то что в ООП не могут, они теорему пифагора не знают. В большинстве своем они даже html/css не знают хотя-бы на треть, или еще хуже продают продукт состряпанный на юкозе.

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

[OmegaBerkut]

Сообщение от Alex11223

Это элемент страницы, вот он и увеличивается как и все остальное.

Адаптивность тут при том, что этот элемент находится всегда в пределах монитора. При этом, если ПРИ УВЕЛИЧЕНИИ этот баннер намерено загоняется в монитор - он всё больше уменьшает эффективное рабочее пространство, и перекрывает полезную информацию.

Naive
Согласен, что вопрос в данном случае касается правильности применения тех или иных средств реализации. Но бывает и так, что средства реализации не продуманы в полном объеме. Конкретный пример - то, о чём мы уже общались в этой теме: визуальный конструктор для веб-сайта генерирует кучу мусора, а это означает, что методы генерации кода продуманы не полностью.

[Alex11223]

Это не адаптивность, а автор так захотел. Нахождение в пределах экрана никак не относится к адаптивности, всегда существовали "модальные" диалоги. Ну а увеличение просто так работает, вряд ли кто-то что-то намерено делал.

[Пепел Феникса]

а это означает, что методы генерации кода продуманы не полностью.

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

HTML настолько гибок, что многие вещи можно сделать 100-ей способов.

[OmegaBerkut]

Сообщение от Пепел Феникса

HTML настолько гибок, что многие вещи можно сделать 100-ей способов.

Как то мне рассказывал препод, что любую задачу по программированию можно решить сотней способов. И HTML тут не причём. Даже проводился эксперимент: брали случайных 10 студентов примерно одинакового уровня развития, давали одну и ту же задачу (на десктоп). В результате - 10 методов решения, кардинально отличающихся друг от друга (математический и логический аппарат). Но это уже другая история.
Я немного почитал про CSS, в принципе, ничего сложного ... Но это уже касается конкретных стилей конкретных компонентов. Я же изначально спрашивал, почему нет визуального редактора, где можно швырануть кнопку, задать точную позицию, привязать событие OnClick, и радоваться жизни ...
Грубо говоря, на том же аспе при создании какого либо компонента все его поля принимают значения по умолчанию. В тегах объявления компонента нужно указывать значения НЕ по умолчанию для конкретного значения - то есть каждое поле прописывать. И чем больше используемых полей, тем больше кода. А общей картины не видно до запуска страницы. Итого - по аналогии мы получаем стоковую библиотеку MFC (C++) на Visual Studio до версии 2008 года. В MFC тоже все компоненты и их параметры когда то нужно было прописывать руками без визуального редактора. И это был геморрой.