id: Гость   вход   регистрация
текущее время 13:10 19/03/2024
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 27/08/2014 10:40 (автор: SATtva) Печать
Категории: софт, сайт проекта, ошибки и баги, разное, сообщество
создать
просмотр
редакции
ссылки

Движок openSpace: разработка и доработка


Пожелания и предложения по развитию программной платформы openSpace следует публиковать в параграф Идеи (если она будет принята в план разработки, то её перенесут в параграф Сделать).
Убедительная просьба вносить сообщения обо всех обнаруженных ошибках в работе сайта, багах и недоработках непосредственно в текст страницы (параграф Исправить), но не в комментарии документа!
Основой платформы сайта служит движок openSpace, представляющий собой сильно модифицированную wiki-систему WackoWiki. Выбор пал на нее из-за простоты устройства, модульности, позволяющей легко изменять систему и подгонять под специфические нужды, наконец, субъективная характеристика — код написан на PHP, и для хранения данных используется БД, а не файловая система.


Поскольку сайт не является wiki в обычном смысле, движок подлежит ряду доработок. В частности, от поддержки ВикиИмен оказалось больше вреда, чем блага, поскольку большинство страниц раскиданы по кластерам, а не размещены в корне сайта, и экранировать все встречающиеся слова со смешанным регистром не слишком удобно. Есть и другие изменения, внесенные в оригинальный движок: основные из них перечислены ниже.

Сделать


  • Элементы страницы для работы с сетью доверия
  • Компонент динамического управления рабочими группами
  • Компонент администрирования пользовательских профилей
  • Дополнительный флаг для прав доступа: изменение свойств и правка документа должны быть подтверждены подписью PGP
  • Усиление защиты аккаунтов:
    • привязка (salt) в пользовательских паролях (защиты от тривиальных и идентичных паролей, rainbow-атак)
    • хранить в базе данных H(H(pwd)), в cookie — H(pwd) (защита при компрометации БД), снимаю шляпу перед Стивом Мёрдоком

Переход к бета-стадии (v0.9b)

  • Инсталлятор
  • Права доступа на участие в опросах (и просмотр определённых опросов?). Также указывать ID опросов для упрощения ссылок на них. Возможность комментирования опросов. (Перенести опросы в адресное поле документов, но использовать специфический хэндлер?)
  • Соответствие XHTML 1.0 Transitional
  • Универсальная (многоязычная) адресация страниц. Требуется: 1) заглавная страница для каждого языка, 2) уникальный ключ на поля { lang, tag(?), supertag }.
  • Вывод страниц в кодировке UTF-8
  • Полный рефакторинг кода:
    • хэндлеры, действия и административные модули переписать в классы вместо inline-php
    • вынести lang-strings действий и хэндлеров в самостоятельные динамически подгружаемые lang-файлы

Исправить


    • Поправка: более детальное тестирование показало, что в определённых случаях проблема сохранилась. Однако, стало возможным отключение части функций типографики (в частности, обработки кавычек) без ущерба для остальной функциональности. Окончательное решение пока не найдено.
  • Несколько подряд вызываемых редакций одного и того же комментария имеют один и тот же урл, что приводит к невозможности редактировать несколько раз подряд один и тот же комментарий в браузерах с активным использованием хэша (links, elinks и другие).
    • Примечание: в связи с технической сложностью и нехваткой времени решение этой проблемы отложено на будущее.
  • При использовании BBCode-разметки если использовать цитирование в списке, сообщение выводится некорректно (большая часть не выводится вообще), не говоря уже о корректном форматировании.
    • Обход: использовать только wiki-разметку в указанном случае.
  • Нет связи с главным ключём при подписывании материалов, т.е. при смене подключа для подписи выдаёт: "неопределенная ЭЦП ключом 0x12345678, не зарегистрированным на сайте". Чтобы избежать такой ошибки, нужно либо вручную обновить ключ на сайте (удалить и загрузить по-новой), либо отправить на сервер ключей и дождаться, пока сайт в плановом порядке обновит его сам.
  • В броузере Opera не отображается панель Wiki разметки, что делает неудобным оформление постов. Прошу обязательно исправить.
    • Код панели разметки несовместим с Оперой. Он целиком заимствован из WackoWiki. Если разработчики решат его исправить, исправление будет принято и в oS. Либо исправьте сами и пришлите патч.
  • Поиск: если в поле "Автор" указать "Гость", то поиск не срабатывает. Контрпример: поиск слов "pgpru" или pgpru* возвращает "Результатов не найдено", хотя есть (один из примеров) /comment43978.
  • При вставке ссылки, содержащей кириллические символы, копированием из firefox (например, из русской википедии), бьётся кодировка, и ссылка становится нерабочей (сайт не делает преобразование "URL-encoded → UTF-8").
    • Обходной путь: перенабирать кириллические символы в ссылках руками при вставке в вики-документы.

Идеи


  • Возможность загрузить в профиль электронную визитку (vCard ver. 3.0) и её подпись.
  • Автоматическое получение метки времени на каждую редакцию документа.
  • Замена RSS 2.0 на Atom 1.0 (RFC 4287), как на свободный и более современный формат.
  • Добавить тэг [offtopic] (можно сокращённо [off]), чтоб по умолчанию (без клика) показывал бы только одну строку, в начале которой он стоит, а по клику веcь блок до закрывающего тега [/off]. Или даже сделать тег [subtopic имя_подтемы], при клике на котором будут раскрыты все субтопики с этой подтемой.
  • Было бы не плохо сделать древовидными комментарии: ответ на комментарий дается под конкретным постом, а не просто в общей ветви. Так же полезно добавить возможность отображения комментариев как с первой записи, так и с последней (новые записи в начало)
  • Надпись "Комментарий добавлен" лучше сделать зелёной.
  • Поиск попросту не работает, use-case нулевой, я в шоке! (пункты 2 и 3 — крайняя необходимость, 1, 4, 5 и 6 — можно отложить на потом):
    1. Так называемый
      стандартный поисковый синтаксис: знаки "плюс", "минус", "звездочка", скобки и т.д
      должен быть описан, либо дана ссылка на его описание. Мне, например, совершенно неочевидно есть ли отличие "слово1 + слово2" от "слово1+слово2". Так же, не ясно как использовать скобки. Выводить каждому эти правила эмпирически — не лучший подход.
    2. Очень существенная часть полезной информации размещена как комментарии к каким-то, зачастую слабо связанным с темой самого комментария, темам. Найти эти комментарии очень трудно. Ввиду этого наличие переключателя "Не искать в комментариях страниц" при отсутвии переключателя "Искать только в комментариях страниц" — форменное издевательство. Предлагается реализовать. Да, и лучше писать "в комментариях к станицам", а не "комментариях страниц" (страницы сами комментируют?) — так точней и звучит лучше.
    3. В выводе результатов поиска вместо того, чтобы (как и делают поисковики типа гугла) показывать кусок текста, содержащий искомое слово или их комбинацию, всегда выводится начало комментария. Не трудно догадаться, что если искомое слово (предложение, цитата) — где-то в середине "простыни", часто посвящённой ответу на несколько слабо связанных между собой вопросов, то догадаться, где же оное среди десятков безликих шапок комментариев, практически невозможно. Это ключевой момент, который полностью обесценивает наличие поиска на сайте. Если трудно сейчас реализовать вывод контекста, путь хотя бы найденные комментарии выводятся полностью, целиком.
    4. В выводе результатов поиска, в порядке очень странного и необъяснимого исключения, показывается сам вики-сорс со всей текстовой разметкой вместо того, чтобы показывать собственно результат её действия. Это улучшает восприятие? Кроме того, это существенный privacy leak: одно и то же "на печати" можно получить разными способами и используя разные форматы (BB, вики-разметку и т.д.), и в самих комментариях этого не будет видно, зато отлично видно в поиске: кто, и как в точности использует эту разметку и какие именно из её элементов.
    5. В поле "Автор" логично было бы включить поддержку списка пользователей (не забывайте, что Гость — тоже пользователь!). Т.е. если указано "SATtva, unknown", это бы значило "все документы/комментарии, опубликованные либо SATtva'ой, либо unknown'ом".
    6. Было бы очень кстати реализовать поиск по документам/комментариям, появившимся за последние n месяцев (или m лет, если им больше года), добавив соответствующее поле/параметр. Часто хорошо помнится, когда примерно было опубликовано то или иное, но вот поисковику на сайте это не объяснить.
  • Разрешить при создании темы вводить ограничения для комментаторов. Например, запрещать им писать под гостем, чтобы псевдоним в теме был обязателен. Или, если более общо, можно разрешить вводить допусимую (для создателя темы) долю таких комментариев (на каждой странице или во всей теме)
  • Выделение цитат <[цитата]> неудобно по двум причинам: нужно переходить в латинский регистр и символы разные. А ведь это одно из наиболее часто используемых форматирований! Ну и поскольку в первую очередь оптимизировать надо самое частое, то хорошо бы добавить возможность выделять цитаты на русском регистре и повтором символа, например ;;цитата;;. Или лучше \\цитата\\ – даже на шифт не надо нажимать.
  • При использовании сносок (разметка наподобие ((*1)) и ((#1))) оные относятся ко всей странице, а не к комментарию, где они нужны (т.е. если в одном комментарии уже есть первая сноска, то первую сноску во втором комментарии необходимо нумеровать как минимум с двух). Лучше, когда каждый комментарий — "корнем" для собственных сносок. При желании сослаться на объект в других комментариях или на объект в самом топике можно воспользоваться другими элементами wiki.
  • Появление нового опроса не отображается в "последних изменениях". Почему бы не добавить? Сайт проще всего отслеживать по странице последних изменений и последних комментариев — там должны быть отражены все изменения, произошедшие на сайте. К тому же, было бы намного удобней иметь не 2 страницы ("комментариев" и "изменений"), а одну, где все изменения отражены.
  • Подобно черновикам в wiki удобно было бы иметь поддержку «черновых комментариев»: возможность к каждому треду обсуждений писать и сохранять черновик комментария, который не будет никак отображаться в треде до тех пор, пока не будет официально отправлен. Мотивация: длинные комментарии, дорабатываемые втечение длительного времени, пишутся долго и при этом нигде не сохраняются, кроме как во временном буфере сообщений, потому падение браузера приводит к потере всего комментария. Можно подумать над тем, как такую опцию сделать непротиворечащей анонимности (иметь черновики комментариев так же для гостей).
  • Сделать поддержку тегов для форумных веток и новостей. Теги могут придумываться/назначаться пользователями и меняться постфактум. Это позволило бы объединять набор новостей на определённую тему (к примеру, cold boot атаки) в одну виртуальную тематическую подшивку, а также упростило бы поиск.
  • Подобно тому, как это сделано для самих тредов и новостей, хотелось бы иметь возможность просматривать referrers для каждого комментария на сайте (список тем и комментариев, которые на него ссылаются). Цель — упрощение тематического поиска.
  • Ряд обёрток (box, wacko) не закрывают контекст в конце комментария, из-за чего конец комментария не является реально концом, и один комментарий начинает обтекать другой при неаккуратном форматировании. В итоге, из-за ошибок в разметке одного гостя портится форматирование и последующих постов от других гостей. Исправить.
  • Имеется проблема с двойным минусом при его использовании в комментировании wiki-сорса. PoC: %%(comments) тест -- тест%%
  • Подстроку вида Гость (24/05/2013 13:02) автоматически превращать в ссылку, если она встречается в тексте.
  • 10 – 50 – 100 – 500 комментариев на страницу. 20 листов комменариев, невозможно читать, а так развернул одной страницей, полистал, и задача поиска пропадает, F3. Можно открыть страницу в режиме печати (ссылка в правом верхнем углу).
  • Большинство форумов и, например, livejournal поддерживают стандартный обычный html. Почему бы не сделать так, чтобы разметку можно было прямо в комментариях оформлять, да и плюс с поддержкой стилей? Было бы здорово и очень просто.
  • SatVa, запили, что бы можно было youtube ролики вставлять в ветвь обсуждения? Нафиг.
  • SatVa, верни картикни? Например, всякие блок-схемы тех же шифров, иногда, лучше 1 раз увидеть, чем пять листов прочитать. Локальные изображения работают. Поддержка удалённых неприемлема из-за HTTPS mixed content.
  • Сделать тэг, чтобы можно было что-то убрать под кат (например исходник LaTeX-формулы, которая вставлена картинкой).
    • На данный момент может быть убрано в html-комментарий: %%(comment) текст %%

 
На страницу: 1, ... , 20, 21, 22, 23, 24, ... , 26 След.
Комментарии [скрыть комментарии/форму]
— SATtva (17/01/2014 12:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Ещё раз: речь об атаке со стороны сервера или его оператора. Например, добрый SATtva ставит на сервер pgpru.com такой веб-клиент. К доброму SATtva'е приходят злые полицаи добрые полицейские и говорят: "Мы подозреваем, что через Ваш сайт переписываются российские оппозиционеры арабские террористы. Дайте нам их послушать, ни то больно будет устроят теракт, погибнут люди". Тогда доброму SATtva'е придётся стать злым и изменить код веб-клиента, чтобы он встраивал сеансовые ключи в передаваемые сообщения, которые потом перехватит СОРМ. А учитывая, что js-код каждый раз скачивается с сервера заново, к оппозиционерам террористам вскоре приедет чёрный воронок прилетит крылатая ракета. Теперь фирштейн?
— ressa (17/01/2014 18:27)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Фирштейн, просто я думаю, что если придут и скажут – то плевать, что у тебя там js или Python, да хоть на asm сайт написан. Отталкиваемся от того, что в паблике все читается, ну т.е. ты хоть gmail покрывай gpg – письма все-равно складируются до лучших времен, когда будет возможна дешифровка. Но в принципе – я тебя понял, т.е. безопасности не дает ничего, что хостится на чужих серверах.
— Гость (18/01/2014 01:24)   <#>
Шифрпанк и кулхацкерство

Стадия первая:
Нужен сервак, который (нам астрал сказал ему верить) не вёл логов, не ведёт и не будет вести. То, что логи ведутся СОРМом (или ещё и хостером), кулхацкеры не знают.

Стадия вторая:
Никому нет доверия. Нужен свой сервак в доверенной юрисдикции. То, что логи при этом ведутся СОРМом (или ещё и хостером, какая бы ни была юрисдикция), кулхацкеры не знают. Почему-то у них принято доверять хостеру, которого они ни разу даже в глаза не видели. То, что хостера могут принудить к сливу информации по закону, закрыв ему рот кляп-ордером, кулхацкеры тоже не знают.

Вывод:
Нет доверия железу, которое в руках противника. Промежуточная сторона должна хранить только шифрованную информацию без ключа к ней. Всё должно шифроваться end2end. Будущее — за распределёнными анонимными сетями. Джаббер давно идеологически устарел, нужно средство типа TorChat, но общепризнанное, доверенное и прошедшее аудит.

Публика PGPru тоже проходила эти стадии кулхацкерства, так что вы не подумайте чего такого...
— Гость (20/04/2014 00:12)   <#>

Правила местной разметки для кретинов

которым похрен на всё, и которые не собираются читать документацию wiki.

  1. Нажми на предпросмотр, пофикси переводы строк, прочитай свой текст, исправь ошибки.

  1. Через «>» цитируется цитата собеседника, на которую пишется ответ. Чтобы не было лишних переводов, перед строкой с ">" должно быть две пустых строки, а после — ни одной. Показываю пример:
    > текст цитаты
    текст ответа
     
     
    > текст цитаты-2
    текст ответа-2
    Если нужно несколько строк вставить в цитату, не обязательно в начале каждой строки ставить «>» — достаточно поставить принудительный разрыв, а если надо, то и принудительную пустую строку:



    На печати оно будет выглядеть так:


    текст ответа

    Более ранние цитирования аналогично помечаются через два знака, «>>», ещё более ранние — через три, и т.д. Но тут есть косяк: начиная с трёх, надо делать квотирование перед третьим символом, т.к. разметка глючит:
    >>"">>>"" Пять квотирований
    На печати будет:


    Напоминаю, что разметка — не часть слова и не знак препинания. Не пишите её вплотную к тексту, ставьте пробел:


    >Неправильно

    Если в цитате нужно написать мелкий шрифт (см. пукнт 8), то ставьте переключатель на него после знака «>»:
    > ++мелкий шрифт++
    т.к. именно первый знак в строке включает голубой цвет для цитаты.

  1. Все остальные цитаты пишутся как собственно цитаты: <[текст цитаты]>. На печати они выглядят как

    текст цитаты

    Перед такой цитатой (внутри текста, естественно) нужна одна пустая строка, после неё — ни одной. Переносы и абзацы охватываются такой цитатой искоробки. Если в цитате используются строки, начинающиеся с пробелов, это будет интерпретировано, как простановка отступов или формирование списков — в этом случае закрытие знака цитирования «]>» должно быть на следующей строке, иначе текст перекорёжит.

  1. Весь код заключается в квотирование для кода: %%my code%%. Это убирает срабатывание разметки и ставит для него моноширинный текст, который не будет портить форматирование. Если переводов строк вокруг кода не поставить, он будет примыкать к тексту вплотную, в отличие от хайлайтера (см. пункт 5), поэтому проставляйте лишние переводы строк, где это уместно. К тому же, после кода всегда добавляется (внутри квотирования) лишняя пустая строка, что плохо. Там, где уместно, предпочитай хайлайтеры (пункт 5), а не чистый код (этот пункт).

  1. Для неширокого кода можно включить подцветку:

    %%(hl css)# pkill -9 cretins%%

    Или:

    %%(hl javascript)# pkill -9 cretins%%

    Или:

    %%(hl diff)# pkill -9 cretins%%.

    Полный список — в документации вики, смотрим на хайлайтеры. Не ставьте хайлайтеры для кода с длинными строками в нём — автоперенос для них не работает, страницу разнесёт. В отличие от кода, нужные отступы строк вокруг хайлайтеров проставляются автоматически, поэтому их нужно писать слитно с текстом:

    «текст%%(hl css)my code%%продолжение текста».

  1. Все имена исполнимых команд и сами команды принято писать моноширинным текстом: ##pkill -9 cretins##. Если вы для написания кода не используете разметку пунктов 4 и 5, включите моноширинность и позаботьтесь о подряд идущих двух минусах (пункт 9) и квотировании тильд (пункт 10).

  1. В книгах не принято делать перенос строки, где вздумается. В интернет-текстах тоже. Перенос строки = начало нового абзаца. Движок автоматически расставляет переносы там, где нужно, не делайте бессмысленных переносов строк. Если нужно начать новый абзац, сделайте перед ним пустую строку — это стандарт форматирования текстов в сети.

  1. Мелкий шрифт ставится так: ++мелкий++. Внутри мелкого текста не должно быть явных переводов строк. Если вам нужно закомментить абзац, вы либо делаете все переносы скрытыми через «---», либо ставите два плюса в начале и в конце каждой строки. Сквозь принудительную пустую строку
    ---"" ""---
    мелкий шрифт тоже пробрасывается. Недопустимы только явные переводы строк. Это же правило касается подчёркиваний: __подчёркнутый текст__; моноширинного текста: ##моноширинный текст##; но не касается выделения цветом: !!(blue)синий цвет!! и зачёркиваний: --зачёркнутый текст--.

  1. Два минуса подряд — зачёркнутый текст. Если их надо поставить (например, в командах: --value=parameter), квотируйте их двойными кавычками:
    ""--value=parameter""
    или пишите их внутри форматтеров кода / внутри хайлайтеров (пункты 4 и 5).

  1. Тильда — знак разметки. Чтобы напечатать одну тильду, как есть, напишите две тильды подряд. Другой вариант — заквотируйте её в двойные кавычки как в примере пункта 9.

  1. Сноски на самом деле кликабельны, поэтому если хочется сделать сноску, ставь сноску, а не «звёздочки в степени». Сноска: ((*)); расшифровка сноски: ((#*)). Вместо одной звёздочки можно писать две. Три и более — нельзя. Если нужно три и более, используй цифры: ((*15)), ((#15)). Сноски крепятся к текущей странице, а не к комментарию или документу, поэтому прежде, чем придумывать название для сноски, просмотри, используются ли уже какие-то сноски на ней, и если да, то не повторяй уже задействованные лейблы для сносок.

  1. Если пишешь ответ на тот комментарий в треде, который написан последним, иногда можно не цитировать конкретную фразу, на которую отвечаешь. В остальных случаях цитирование (но не оверквотинг!) горячо приветствуется, чтоб было понятно, к чему ответ-та. На одной странице по умолчанию отображается 15 комментариев. Часто так получается, что ты добавляешь комментарий, но он будет n mod 15 = 1, из-за чего он становится единственным комментарием на следующей новой странице. Открываешь эту страницу и думаешь: «к чему он сказан?». Ну а если сознательно цитируешь комментарий с предыдущей страницы/страниц, поставь ссылку. Ссылка нужна не потому, что все забыли, о чём речь, а потому, что через 5-10 лет ни ты, ни другие не вспомнят, о чём шла речь, а корректная простановка ссылкок существенно облегчит освежение дискуссии в памяти. Это как комментарии к коду, их надо писать.

    Стандарта на цитирование здесь нет, но есть простые правила:

    1. Не пиши кишки: https://www.pgpru.com/comment75896 — неправильно, ((/comment75896)) — правильно, ((/comment75896 комментарий)) — тоже правильно. Вместо двойных круглых скобок можно брать квадратные.

    2. PGPru — вики. Все ссылки крепятся к корню как в UNIX, поэтому пути надо указывать от корня: ((/comment75896)), ((/razrabotki/dvizhok)) и т.д., смотри на адрес ссыки. Т.е. начало «https://www.pgpru.com» отовсюду вырезается. Плюс правильно поставленных ссылок в их независимости от домена. Если сайт сменит домен, или будет поднято зеркало на другом домене, правильно поставленные ссылки продолжат корректно работать, а твои кишки — нет. У правила есть важное исключение: внутренние ссылки, содержащие знак вопроса, нужно писать полностью, начиная с «https://www.pgpru.com». Таких ссылок на сайте немного, и даже для тех, что есть, имеются алиасы, позволяющие этого избежать. Например, ссылка на профиль содержит знак вопроса:
      https://www.pgpru.com/proekt/poljzovateli?profile=ressa
      но вместо неё можно просто написать ((username:ressa ressa)) и получить на печати ressa.

    3. Кириллицу в ссылках, а также все UTF-символы, надо перенабирать руками — движок её кодировку иначе не обработает. Некоторые элементы в ссылках (как, например, два плюса подряд) являются частью разметки, поэтому такую ссылку не проставить как ссылку в принципе. Используй в таких случаях квотирование всего текста ссылки, офомляя её как текст.

    4. Чтоб не думать, где, как и к чему прикрепить ссылку при цитировании внутреннего или внешнего источника (не всегда для неё есть естественное место), предлагаю не переизобретать велосипед, а ставить ссылку на первую букву, делая её для лучшей видности жирной или даже ещё и моноширинной:

      Шифрпанк и кулхацкерство

      Другой пример:

      Шифрпанк и кулхацкерство

      Ещё пример:


      Как не трудно догадаться, это разметка:

      1. **((/comment75896 Ш))**ифрпанк
      2. ##**((/comment75896 Ш))**##ифрпанк
      3. ##**((https://ru.wikipedia.org/wiki/Криптография к))**##риптография

      Писать первую букву фигурным образом было принято в старых текстах, но как элемент красоты это правило сохраняется не печати и сейчас во многих современных изданиях, включая статьи при криптографии (смотрим стилевой LaTeX-файл IEEE).
— Гость (20/04/2014 00:23)   <#>

Правила местной разметки для кретинов.


Фигасе как у разметка-кун бомбануло.
— Гость (20/04/2014 13:22)   <#>
а это опять спинора беснуется
ему простительно
— SATtva (20/04/2014 14:53)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Гость (20/04/2014 00:12), спасибо, хорошая выжимка.
— unknown (21/04/2014 10:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В целом пример безусловно полезный, чтобы иметь под рукой краткую выдержку из документации по местной вики-разметке. Что-то вроде tip-sheet. С предложением о соглашении по тому, как это лучше использовать именно в форумных постах.

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

Цитата собеседника очевидно ставится через ">", как принято в рассылках, да и здесь логично подсвечивается. Но длинная цитата, а иногда бывает нужно сделать разумный оверквотинг, IMHO в таком виде выглядит не очень. Даже если аккуратно расставить все межстрочные переносы и абзацы. В таком случае удобнее и визуально нагляднее всё равно через <[ ]>, также как и для внешних цитат, но при этом, разумеется, указать ссылку на цитируемый пост.

Недаром же был приведён пример:

Шифрпанк и кулхацкерство


Т.е., ">" и вложенные ">>" — это хорошо для коротких цитат собеседника, а для длинных — всё равно <[]>. Не настаиваю на обязательности, просто это неочевидный вариант, по которому могут быть разные аргументы «за» и «против». Опять же, варианты указать ссылку на пост, с которого взята цитата, могут быть разные. Однозначно сказать, что один лучше другого, не во всех случаях возможно. Например, когда в одном посте идут ответы на разные коменты и разным собеседникам, можно сделать ссылку вида SATtva (17/01/2014 12:20):, далее ">"текст цитаты, затем ответ, затем Гость (20/04/2014 00:12): и ответ на его цитату. Чтобы была связь между комментариями не только по наведении курсора на ссылки, но и визуально можно было запомнить, кому, что и на что отвечают.

Другое не(до)понимание вызывают сноски. Понятно, что они кликабельны и удобны для больших документов. Но именно для отдельно размещённых документов. Для форумных постов, IMHO, ссылки вообще не предназначены. Другое дело, что некоторые посты претендуют по объёму на массивный и исчерпывающий документ, с возможностью на его основе создать постоянную страницу, или даже его переноса в отдельный раздел с документацией. Может быть в форуме опубликован в ходе обсуждения и черновик чего-либо, со сложной структурой, оглавлением, ссылками. Но это опять же дискуссионный вопрос, как это всё лучше делать. Я теперь лучше понимаю, почему некоторым хотелось рассылку. Там это органичнее, каждый пост — это отдельное письмо, которое можно рассматривать как отдельный документ (особенно когда в рассылках шлют черновик документации проекта). И связь между постами не такая сильная. Насколько это органично для форума — вопрос дискуссионный. Можно предположить, что в форуме идут слабоструктурированные обсуждения, часто на скорую руку. Вместо чёткого структурирования и ссылок могут быть пометки и разъяснения прямо в тексте. Как только из этого вызревает претендент на законченный документ, который есть желание развивать, то это следует делать на отдельной вики-странице. Да, анонимный постинг тогда не получится, только псевдонимный.

Могут быть и ещё какие-то соображения, когда вопросы разметки выходят за рамки элементарной аккуратности оформления и пересекаются с вопросами соответствия оформления и содержания.

Ещё раз: рекомендации безусловно полезны, но часть правил в них никак не относится к кретинам, а наоборот к любителям публиковать сложные и содержательные посты (или с претензией на таковые), которые в смысловой формат форума (как движка, платформы для обсуждений) еле влезают, но оформить их как-то поприличнее надо.
— Гость (22/04/2014 05:10)   <#>

Пожалуйста. На самом деле, это собрание костылей, где костыли на костылях сидят и костылями погоняют, но другого пока нет. Там далеко не обо всех секретах сказано, упомянул только о том, чем пользуюсь чаще всего. В более сложных случаях приходится часто приходится экспериментировать, благо предпросмотр всегда работает (но и он не всегда даёт ту картину, какая будет после сохранения). Например, дополнительные отсутпы вокруг пунктов в списках вложенности два и более достигаются костылём
---"" ""---"" ""
Никак проще этого не добиться.

Ещё есть вопрос, что будет со всем этим хозяйством при переезде на новый движок. Будет ли реинтерпретирована существующая разметка, что приведёт к полному испохабливанию изменению внешнего вида ранних документов wiki? Переезд 2006-го года был как раз примерно таким. Хотелось бы, чтоб новые правила разметки применялись только к новым постам, иначе будет тотальный бардак.


Даже если абзац всего один, т.е. не содержит дополнительных строк, вы всё равно используете <[]>, что я никогда не понимал. Внешний вид — отдельная тема, мне тоже не всё нравится, но я скорее склонен принести его в жертву в пользу чёткости разметки.


Хочу подчеркнуть, чтобы не было недопонимания, что внешние цитаты — это не только все цитаты с других сайтов, но и цитаты из поста/постов выше, которые вы хотите процитировать в своём ответе, т.к. они являются частью вашего ответа (т.е. могли бы быть заключены в кавычки, если б это был текст книге), но не тем, на что вы отвечаете в своём сообщении. Вот пример:
Пост-1
Мы, люди-криптографы, не в состоянии правильно использовать разметку на pgpru.com.
Пост-2

Как же так? Вы же сами про себя пишете:

люди-криптографы

что, мягко говоря, не вяжется с недостатком интеллека.

Всем сейчас понятно, что не все «внутренние» цитаты должны идти через «>»?


В общем, я «против». Во всяком случае, в TBB я уже привык к тому, что как выглядит. Больших претензий к внешнему виду теперь нет, хотя в других браузерах при других шрифтах те же элементы могут выглядеть как лучше, так и хуже.


Раньше, когда большинство постов на сайте было негостевым, это было распространённой практикой, но потом ушло.


«Не дружит с анонимностью». Вы продолжаете разговаривать с людьми и личностями, а не с аргументами. Вам важнее, кто сказал, чем то, что было сказано? Если кто-то не подписывается, то метка времени в цитировании добавляет практически ноль информации, т.к. у разных постов одного и того же Гостя она будет разной. Можно разве что собрать все посты, которые похожи на то, что написаны одним анонимом, а потом прикрепить к этому имени идентификатор, и уже его указывать в цитировании. ☺ Но это будет уже совсем агрессивно.


Я не согласен. Сноска — это возможность не писать длинное пояснение в скобках, препятствующее его чтению/парсингу. Считается, что в скобках надо писать только то, что строго необходимо для понимания текста при первом его чтении, всё остальное идёт в сноски, пояснения, аппендиксы, приложения и пр. Если нечто нельзя понять правильно без конкретного пояснения, я его оставляю в том месте текста, где оно нужно. Всё остальное выносится в сноски или пояснения в конце текста. Это делает основной текст короче, яснее, лаконичней, доходчивей.


Когда нормальный человек постит и видит, что вышла хрень, он извиняется, просит исправить, пытается найти причину ошибки и учесть её на будущее. Все следующие посты он проверяет в предпросмотре и исправляет проблемы. Когда пишет кретин, он видит, что получается чушь, но с упорством, достойного лучшего применения, он не шевелит даже пальцем, чтобы что-то исправить. Он считает, что исправлять текст и его форматирование в предпросмотре — ниже его достоинства. Ему всё равно, что и как пишут/оформляют другие, всё равно, какие правила на ресурсе, он их не уважает, не встраивается в систему, он делает то, к чему привык. Привык гадить на имиджбордах если, то приходит и здесь пишет так же. Привык не ставить заглавные в чатах — и здесь ведёт себя так же. Это игра на проверку прочности SATtva'ы. Лично я бы сносил за небрежную грамматику и оформление. Сделал замечание, и если не исправился — добро пожаловать в удалённые. Вы все прекрасно знаете примеры такого поведения здесь.

А для «любителей публиковать сложные и содержательные посты» можно было бы написать ещё один похожий пост не меньшего размера с обсуждением уже «продвинутых» тонкостей:
  • Неоговоренные в документации косяки с именованием якорей.
  • Эквилибр при буквальном включении текста одних wiki-страниц в другие.
  • Магия на UTF- и html-символах: как сделать так, чтобы при повторном редактировании они не превращались в знаки вопросов несмотря на то, что движок не поддерживает UTF? Советы знатоков.
  • Мультииндексные объекты — как обойти ограничения разметки.
  • Специальные символы-модификаторы в UTF, позволяющие печатать надстрочечные и др. символы над произвольными буквами.
  • Что можно и что нельзя сделать форматтерами?
  • Misuse & abuse разметки:

    А вы умеете так писать?

    Наверняка ведь нет...
    Секрет прост, но:

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

    Есть такие вещи, которые знать не положено.


— SATtva (22/04/2014 10:04)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Например, дополнительные отсутпы вокруг пунктов в списках вложенности два и более достигаются костылём <...> Никак проще этого не добиться.

Очень странно, принудительная нумерация пунктов (2.#2) всегда работала, но теперь действительно даёт неверный результат ниже первого уровня. Подозреваю, что-то сломалось с обновлением PHP.

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

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

Во вторую очередь хочу привести некоторые правила к единообразию (вот какого фига ++ работает в пределах абзаца, а !! — на произвольном блоке текста? почему при одном типе цитирования надо расставлять пустые строки так, а при другом — иначе, и почему пользователь вообще должен задумываться, как их расставлять?), но только если удастся сохранить обратную совместимость либо чисто конвертировать старый формат в новый при переносе базы данных на новый движок.

Что же касается хаков типа последнего в Вашем посте, под них я подстраиваться не буду, и их в итоге скорее всего перекорёжит. You have been warned.

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

Боюсь, я не осилю написать настолько баг-совместимый код, чтобы в исходном виде перенести нынешний парсер.

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

Как я уже говорил, внешний вид — штука непостоянная и легко изменяемая через CSS.
— unknown (22/04/2014 10:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Обидно будет, если похерятся UTF-символы и некоторые многоуровневые индексы в формулах. Большого труда стоило напечатать это при существующем движке в приличном виде не просто в постингах, но и в документах, в т.ч. некоторых новостях.
— SATtva (22/04/2014 10:42)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Обязуюсь обеспечить сохранность. В юниттестах будут горы текста из нынешнего движка, так что большинство косяков можно будет отловить на дальних подступах.
— Гость (22/04/2014 10:50)   <#>

Но я не про принудительную нумерацию, я про отступы вокруг. Показываю пример без отступов:
  • Строка первая
    • Строка первая-1
    • Строка первая-2

Теперь оно же с отступами:

  • Строка первая

    • Строка первая-1

    • Строка первая-2

Просто иногда пункты в глубокой вложенности — полноценные абзацы, поэтому, раз мы ставим отступы между абзацами в обычном тексте, логично их поставить и там, не говоря уже про многоабзацный текст внутри подпункта. Вот как выглядит хак:
Показываю пример без отступов:
  * Строка первая
    * Строка первая-1
    * Строка первая-2
 
Теперь оно же с отступами:---"" ""
  * Строка первая---"" ""---"" ""
    * Строка первая-1---"" ""---"" ""
    * Строка первая-2---"" ""---"" ""
— Гость (22/04/2014 11:14)   <#>

Вот напишете вы движок, всё будет ОК, а потом PHP питон обновится, и начнутся пляски по новой. ☺


Я бы предпочёл вообще не завязываться на старый синтаксис и правила, а вместо этого продумать и внедрить новый синтаксис, у которого будет свойство полноты, т.е. который покрывает собой все возможности по форматированию, какие могут понадобиться. Например, можно было бы сделать LaTeX-совместимый (хотя бы в каких-то пределах) синтаксис. Вроде есть сайты и движки, которых кормишь LaTeX-разметкой, а они возвращают ей соответствующий pdf-текст (или картинку), отформатированный по всем правилам. Даже писать ничего не надо — достаточно внедрить. LaTeX, конечно, — ещё тот костыль, но по факту это всеминый стандарт для печати, и такого кретинизма, как у web-разметки, у него нет.

Для тех, кто не интересовался: полноценных конвертеров LaTeX↔Web нет. И задача «вот у меня текст в LaTeX, и я хочу сделать так, чтобы оно так же смотрелось в html» почти нерешаемая для сложно сформатированных документов. И, вообще, в web-вёрстке, говорят, есть множество багов, на которые верстальщики попросту молятся, т.к. никто кроме них не знает всех этих костылей, позволяющих причесать текст, чтобы он смотрелся, как надо.

Если забыть про все эти проблемы, то есть же print-формат (кнопка «Печать» на страницах сверху справа). Может быть, как-то можно зафиксировать итоговый вид в печатном виде, а сорс кода-разметки выкинуть? При запросе старых страниц будет выводиться что-то типа print-формата. Ещё лучше — это умение распознавать print-формат обратно в текст с разметкой, но это, наверно, слишком сложная будет задача (хотя распознавалки картинок в текст существуют, и ничего).


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


Вот они как раз не должны. Это практически стандарт, многие движки умеют выводить символы по их UTF-коду, тут сложно что-то сломать. Проблемы могут быть, максимум, там, где это наслаивается на wiki-разметку (всякие индексы, наклонные шрифты и пр.).
— SATtva (22/04/2014 11:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Я бы предпочёл вообще не завязываться на старый синтаксис и правила, а вместо этого продумать и внедрить новый синтаксис, у которого будет свойство полноты, т.е. который покрывает собой все возможности по форматированию, какие могут понадобиться.

Это нереальная задача. Для таких случаев проще и логичнее использовать inline html.
На страницу: 1, ... , 20, 21, 22, 23, 24, ... , 26 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3