Артём Н. -> 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 из-под винворда :-) >> Суть, собственно, в том, что 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 длиннее одного вызова функции в <script> в ручную написанном HTML - >> >> это признак того, что у автора слишком много свободного времени, и ему >> >> нечем это время занять, кроме как вычисткой потом глюков из результата. >> АН> Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один >> АН> внешний JS, который включает объект её реализующий? Про "много >> АН> свободного времени" - это вы объясните авторам всяких там гуглов и >> АН> ещё 100500 сервисов, которые этим JS буквально пронизаны (местами >> АН> это даже удобно и, бывает, работает). >> Это второй вопрос. Но программа на JS, если она используется, должна >> быть в отдельном файле, а не включена в тот же HTML. АН> Когда как... Ни одного контрпримера не попадалось. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa0za0lo....@wizzle.ran.pp.ru