Re: CLI vs. GUI
23.05.2012 10:10, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Tue, 22 May 2012 22:48:11 +0400:
>
> >> >> >> Так что писать на коленке презентацию, которая будет
> >> >> >> выведена плюс-минус так, как ты ее видишь, еще можно (и то
> >> >> >> не всегда нужно - видел я подобные поползновения печатать
> >> >> >> объявления в ворде...), а HTML - уже ни в коем разе.
> >> >> АН> Как-раз для HTML, GUI необходим. Если, конечно, вы не
> >> >> АН> рассчитываете на то, что все ваши пользователи используют
> >> >> АН> lynx, links, w3m или подобное.
> >> >>
> >> >> Доктор, это ничего, что у меня есть информативный сайт, все HTML
> >> >> которого написаны вручную, старые в vim, новые в emacs? Ключевое слово
> >> >> - "информативный".
> >> АН> Вообще-то, это частный случай, когда требуется преимущественно
> >> АН> подсветка HTML и CSS. С чем VIM неплохо справляется.
> >>
> >> Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном
> >> файле, отчего все еще проще.
> АН> Правильный редактор не должен рассчитывать на то, что всё будет "по
> АН> уму", к тому же, иногда надо смешивать CSS и HTML.
>
> Правильный _для меня_ - имеет право на это рассчитывать. Более того,
> ему рекомендуется так делать. Типа если он не справляется с подсветкой,
> значит, я фигню порю. emacs вполне успешно справляется с задачей ловли
> меня за руку.
А вы будете в своём "правильном" редакторе просматривать исключительно
"правильный код"? :-) Или что-то чужое иногда приходится читать? Да и неплохо бы
дать пользователю _выбирать_, что для него правильно...
> Смешивать CSS и HTML иногда надо. Но если это приходится делать до
> такой степени, что нужна синтаксическая подсветка CSS - фигню порешь.
> Что и наблюдается в случае HTML из-под винворда :-)
Не обязательно (именно про подсветку в CSS, даже когда он в отдельном файле).
Синтаксическая подсветка позволит визуально выделить элементы (я не про помойку
CSS+HTML, а про выделение элементов в самом CSS). Меньше придётся напрягаться,
например, при визуальном поиске (в глаза сразу бросаются имена атрибутов,
например, в "полотне" параметров и "своих" классов).
Меньше усталость, комфортнее работать. Я не прав?
> >> Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя
> >> emacs даже умеет показывать картинки. Лучше б не умел...
> >>
> >> >> А если мне нужно интерактивное веб-приложение, то
> >> >> там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно
> >> >> ручное редактирование.
> >> АН> Хм... Haml - любопытно.
> >>
> >> Угу. Технология создания веб-приложений сводится к тому, что дизайнер
> >> делает дизайн, HTML-верстальщик (это совершенно другой человек)
> >> превращает его в HTML, CSS и набор картинок, а программист превращает
> >> эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов,
> >> которые динамически заполняются данными. Гуй для HTML при этом может
> >> использоваться в принципе только на втором этапе, но тем верстальщикам,
> >> кто пытается его там использовать, быстро отрывают руки. Ну, или
> >> результат получается, мягко говоря, неюзабельным для пользователя.
> АН> Хм. Что, вы хотите сказать, что во всех компаниях, которые
> АН> занимаются созданием WEB-данных (документов или приложений и т.п.)
> АН> и могут позволить себе иметь дизайнера, не имеющего представления о
> АН> вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда
> АН> работают без GUI? Кстати, а дизайнер тоже обязательно, либо не
> АН> использует компьютер, либо работает без GUI? :-) Или, всё-таки, на
> АН> первом этапе тоже есть GUI, только совершенно отличный от GUI
> АН> верстальщика?
>
> К слову, в большинстве контор, занимающихся созданием веб-приложений,
> своего дизайнера вообще нет. Аутсорсят. Дизайнер не работает с HTML,
> поэтому ему гуй для (читаем внимательно!) HTML не нужен.
> Верстальщик тоже работает с гуем - но не для создания HTML, а для
> нарезки того, что сделал дизайнер, и для извлечения оттуда информации о
> цветах :-)
Ну, я про это и говорю (читаем внимательно в предыдущем сообщении): раздельный
ГУЙ. Но дизайнер тоже работает с гуём...
> АН> Кстати, а операторам на станциях например, GUI тоже не требуется?
> АН> :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно
> АН> пытаетесь доказать, что GUI - всегда плохо)?
> Почему-то вы упорно вычитываете в моих словах то, что там не написано.
Ну, потому что мне кажется, что вы упорно доказываете то, что я там вычитываю. :-)
> >> >> Как это выглядит, нужно смотреть в браузере и только в браузере.
> >> >> Желательно не в одном.
> >> АН> Как это выглядит и работает нужно проверять в браузере. Обязательно
> >> АН> не в одном, как говорят. По крайней мере, в наиболее популярных
> >> АН> (или в тех, на которых это будет работать, если это нечто
> >> АН> специфическое). И, затем ещё вносить корректировки для конкретных
> >> АН> экземпляров. :-|
> >>
> >> Тонкость в том, что если у тебя есть информация, то можно написать
> >> достаточно простой HTML для того, чтобы проверять его нужно было
> >> максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски
> >> обычно не шибко нужны.
> АН> Просто выглядящий и преподносящий информацию в удобочитаемом виде
> АН> или просто устроенный? :-)
>
> Все три. Первые два вообще очень тесно коррелируют - чем проще выглядит
> HTML, тем информация в нем удобочитаемее.
Ну да. Вот только от типа информации всё зависит, я так думаю.
> >> >> Мешает он тем, что то, как это выглядит в этом гуе, автор и считает
> >> >> реальным видом документа. А что этот гуй выдает в код, и какой ужас
> >> >> потом в браузере... Это - практика.
> >> АН> o.O Я разве агитирую за "Фронтпэйдж"? Я предполагаю, что автор
> >> АН> имеет представление о том, что существуют разные средства вывода
> >> АН> (и, если уж быть точным, не обязательно визуальные).
> >>
> >> Наличие гуя провоцирует не иметь такого представления.
> АН> Это, как "наличие пистолета провоцирует с кем-то разобраться"...
> АН> Уменьшает порог вхождения.
> АН> Но человек во вменяемом состоянии, вряд ли побежит разбираться с
> АН> кем-то лишь потому, что у него в кармане оружие.
>
> Аналогии лгут.
Но не всегда.
> >> Это второй вопрос. Но программа на JS, если она используется, должна
> >> быть в отдельном файле, а не включена в тот же HTML.
> АН> Когда как...
>
> Ни одного контрпримера не попадалось.
"А он есть..." :-)
Как пример: главная страница или IE.
Главная страница может использовать общий стиль. Но у неё есть некоторые
особенности. Зачем для неё выносить CSS в отдельный файл (читайте отдельный
запрос), если он больше нигде не дублируется?
IE поддерживает условные комментарии (aka костыли), которые приходится применять
потому, что он весьма своеобразно отображает некоторые конструкции (в
тонкостях). Зачем выносить три строчки CSS в отдельный файл? Это неразумно,
поскольку ненаглядно и накладно.
Reply to: