Информация об изменениях

Сообщение Re[6]: Обсудим способы монетизации на примере? от 16.09.2018 22:27

Изменено 17.09.2018 3:51 c-smile

Re[6]: Обсудим способы монетизации на примере?
Здравствуйте, licedey, Вы писали:

L>Здравствуйте, c-smile, Вы писали:



CS>>WPF, WinForms и Delphi они заточены на визуальное создание форм (и только форм кстати). Жертв такой заточки много.


CS>>Файл описания форм там есть не редактируемый руками (как правило) монолит который содержит описание как местоположения так и стилей вплоть до цвета бордюров и пр.


L>Для Windows, как и Xamarin — это XAML. Для Android тоже — xml. Я понимаю о чем вы, для WinForms, Delphi, iOS — это форма-монолит. Но для XML-based — стили также можно вынести

L>в отдельный файл, аналог css.

"стили также можно вынести в отдельный файл" вот как только ты это делаешь ты теряешь возможность WYSIWYG редактирования (как правило).

L>Только вопрос же именно о полноценном формошлепстве для pure-html, а еще лучше Razor. Кто мешает той же MS сделать для веба, тоже самое, что и для Windows/Xamarin?

L>Или гуглу с ангуляром. Под Андроид смогли, а под веб — пишите ручками в разных файлах.

"Под Андроид смогли..." и под Web по-смогли и бросили. Frontpage и Dreamweaver — в руки и вперед.

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

L>для десктопшика.

Да пожалуйста — решений много. WordPress, wix.com для не осиливших.

CS>>HTML же есть другая сущность. HTML это семантическая структура — описывает список элементов на странице.

CS>>А CSS это внешняя сущность — описывает как этот список элементов виден пользователю.
CS>>Т.е. один и тот же HTML может по разному рисоваться на принтере, или на экране или на мобильнике — используются разные стили представления одного и того же дерева элементов.

CS>>Т.е. WYSIWYG редактирование возможно только чистого HTML — т.е. редактирование структуры.


L>Однако же и не возбрано смешивать структуру и стиль. Также как контрол и его свойства для форм. WYSIWYG — это же не только структура, но и атриубуты этих кубиков структуры.

L>Хотя не скажу, что удобней из сотни стилей найти нужную и выбрать там Red.

"Однако же и не возбрано смешивать структуру и стиль." это называется "лапша". В результате получается это вот:



На картине выше представлены три системы стилей — Windows 3.11 кнопочки, Windows XP tabs, Windows 8 window frame decoration and toolbars.

CS>>Со стилями же непонятно что вообще редактировать.


CS>>Ты смотришь на экран и говоришь хочу вот этот текст быть красным и left:400px.

CS>>А что делать при печати? А что делать если эти 400px не помещаются на экране?
CS>>А что делать если <select> на desktop это выпадающий список, а на mobile это полноэкранный пальцевый скроллер. И т.д.

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

L>В Xamarin например, когда мы пишем Margin="400", например, то эти 400 на разных устройствах масштабируются в совершенно разные пиксели относительно размера экрана.

пишем Margin="400" это извиняюсь фигня полная.

На мобильнике и слабом экране flow должен быть vertical с vertical же scroll. А не desktop юзеру будет комфортно если список горизонтальный.

Вот открой http://html-notepad.com/ и поизменяй размер экрана. Ты увидишь три layout models для разных размеров.
Описать это в любой системе WYSIWYG практически невозможно.

В CSS это дело трех строк (условно).

Ты же не пишешь свой код в WYSIWYG?
А мог бы:



Но нет. Или да?

L>Да и я больше за что то вроде left:10%, или пусть будет left:400, но со скейлингом относительно экрана.

L>К сожалению мало силен в html верстке, мне проще XAML дается, который почти тоже самое, только понятней и без необходимости изучать еще с десяток фреймворков, чтобы верстка не поехала.

"скейлингом относительно экрана" не работает.


Portrait/landscape orientation например. Content тот же, layout другой принципиально.

Ну и если размер кнопки становится меньше проекции пальца на touch screen, то ты свой можешь и не начинать писать.
Иначе начинать надо с usability и книжек про эргономику.
Re[6]: Обсудим способы монетизации на примере?
Здравствуйте, licedey, Вы писали:

L>Здравствуйте, c-smile, Вы писали:



CS>>WPF, WinForms и Delphi они заточены на визуальное создание форм (и только форм кстати). Жертв такой заточки много.


CS>>Файл описания форм там есть не редактируемый руками (как правило) монолит который содержит описание как местоположения так и стилей вплоть до цвета бордюров и пр.


L>Для Windows, как и Xamarin — это XAML. Для Android тоже — xml. Я понимаю о чем вы, для WinForms, Delphi, iOS — это форма-монолит. Но для XML-based — стили также можно вынести

L>в отдельный файл, аналог css.

"стили также можно вынести в отдельный файл" вот как только ты это делаешь ты теряешь возможность WYSIWYG редактирования (как правило).

L>Только вопрос же именно о полноценном формошлепстве для pure-html, а еще лучше Razor. Кто мешает той же MS сделать для веба, тоже самое, что и для Windows/Xamarin?

L>Или гуглу с ангуляром. Под Андроид смогли, а под веб — пишите ручками в разных файлах.

"Под Андроид смогли..." и под Web по-смогли и бросили. Frontpage и Dreamweaver — в руки и вперед.

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

L>для десктопшика.

Да пожалуйста — решений много. WordPress, wix.com для не осиливших.

CS>>HTML же есть другая сущность. HTML это семантическая структура — описывает список элементов на странице.

CS>>А CSS это внешняя сущность — описывает как этот список элементов виден пользователю.
CS>>Т.е. один и тот же HTML может по разному рисоваться на принтере, или на экране или на мобильнике — используются разные стили представления одного и того же дерева элементов.

CS>>Т.е. WYSIWYG редактирование возможно только чистого HTML — т.е. редактирование структуры.


L>Однако же и не возбрано смешивать структуру и стиль. Также как контрол и его свойства для форм. WYSIWYG — это же не только структура, но и атриубуты этих кубиков структуры.

L>Хотя не скажу, что удобней из сотни стилей найти нужную и выбрать там Red.

"Однако же и не возбрано смешивать структуру и стиль." это называется "лапша". В результате получается это вот:



На картине выше представлены три системы стилей — Windows 3.11 кнопочки, Windows XP tabs, Windows 8 window frame decoration and toolbars.

CS>>Со стилями же непонятно что вообще редактировать.


CS>>Ты смотришь на экран и говоришь хочу вот этот текст быть красным и left:400px.

CS>>А что делать при печати? А что делать если эти 400px не помещаются на экране?
CS>>А что делать если <select> на desktop это выпадающий список, а на mobile это полноэкранный пальцевый скроллер. И т.д.

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

L>В Xamarin например, когда мы пишем Margin="400", например, то эти 400 на разных устройствах масштабируются в совершенно разные пиксели относительно размера экрана.

"пишем Margin="400"" это извиняюсь фигня полная.

На мобильнике и слабом экране flow должен быть vertical с vertical же scroll. А не desktop юзеру будет комфортно если список горизонтальный.

Вот открой http://html-notepad.com/ и поизменяй размер экрана. Ты увидишь три layout models для разных размеров.
Описать это в любой системе WYSIWYG практически невозможно.

В CSS это дело трех строк (условно).

Ты же не пишешь свой код в WYSIWYG?
А мог бы:



Но нет. Или да (с придыханием в голосе)?

L>Да и я больше за что то вроде left:10%, или пусть будет left:400, но со скейлингом относительно экрана.

L>К сожалению мало силен в html верстке, мне проще XAML дается, который почти тоже самое, только понятней и без необходимости изучать еще с десяток фреймворков, чтобы верстка не поехала.

"скейлингом относительно экрана" не работает.


Portrait/landscape orientation например. Content тот же, layout другой принципиально.

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