Столкнулся с необходимостью (желательностью) давать русские (не-английские) имена actions. Если предполагать, что с вики будут работать не только «компьютерщики» (не люблю это слово, но приходится грязно выражаться), то надо признать, что сервис actions для остальных будет практически недоступен из-за «страшных иноземных слов». Мы ж хотим «интуитивности», не так ли?
Реализовать можно, имхо, через возможность делать aliases (псевдонимы) для actions (например, через препроцессинг или те же пресловутые макросы), а еще лучше (с раскатом губы) иметь возможность создавать группы actions (получаются, конечно, пакетные команды или подпрограммы, почти язык скриптования).
Возврат из include
Когда меняешь составной документ (с includами), то и дело переходишь в режим редактирования include-документа. После сохранения там текста остаешься в просмотре этого инклюда, что не есть хорошо, так как хотелось бы возвращаться в составной документ туда, откуда начал редактирование.
Варианты решения: а) при сохранении include-текста, вызыванного из составного документа, отрабатывать нечто вроде history.go(-2), т.е. возвращаться в родительский (составной) документ. б) в шапке инклюда сделать ссылку на этот составной документ.
Кстати, есть ли экшн, позволяющий узнать, в какие составные документы вставлен текущий?
Чудо! Свершилось чудо! Часть моего разума переселилась в вику и она переименовала мои файлы в пользу сестры таланта :-) А я то думал, что только владелец страницы способен на это...
RomanIvanov: Не только. Ещё админ. Я как поглядел на ресентченджес, я чуть в обморок не упал, там всё раскорячило. Вот и переименовал.
ВадимБарсуков: Чувство, будто обрезание сделали без предупреждения :-)
О троеточии
Не сочтите за придирки, но кажутся мне странными эти три точки в шапке страницы OversiteWiki: ВадимБарсуков/Предложения .... Они воспринимаются как слова «и т.д.», так как традиционно эдак размечают часть строки, не поместившуюся в видимой области. Ощущение, что далее последует детализация структуры страницы (в данном случае страницы Предложения).
Может пиктограмму поиска поставить? Лупу какую-нибудь.
RomanIvanov: ИМХО, это почти стандарт в виках. Если вы сделаете небольшой обзор по разным викам и сведёте данные в таблицу, то мы на неё поглядим и подумаем о более интуитивном способе.
ВадимБарсуков: Обзор сделать можно, но почему мы (вы) настолько привязаны к неким «стандартам» вики? Предполагается, что бОльшая часть пользователей Wacko Wiki? уже имеют значительный опыт работы с другими виками?
RomanIvanov настоятельно предлагает обсудить Вам этот вопрос с Andrey Cherezov?.
О наблюдении
Сдаётся мне, что:
настройку флага «наблюдать/не наблюдать» имеет смысл добавить на страницу управления ACL. Автору удобно: создал страницу, если надо поправил права и выставил наблюдение.
при создании страницы надо отмечать её по умолчанию как «наблюдаемую» для автора страницы. Если спорно, то можно регулировать такое дефолтное поведение в wakka.config.php как параметр default_xxxxxx.
нужно наследовать «наблюдаемость» при создании дочерней страницы (аналогично правам). Для автора безусловно, а для других наблюдателей родительской страницы в этом не уверен.
если страница на наблюдении, а в ней инклуды, они автоматически не ставятся на «досмотр»? Если так, то, может, сделать фичу «наблюдать и за вложенными»? как в анекдоте: Сталин: Это фото вырезать! -Берия: И всю семью!
Сворачивание/разворачивание фрагментов
Подумать над возможностью сворачивания/разворачивания фрагментов текста (в частности, инклюдов). Так можно было бы организовать дискуссии «внутри» текста: хочешь читать только текст документа свернул все вставки, хочешь посмотреть обсуждение разверни вставку. А если все обсуждения выносить в инклюды, вообще лафа: разносим текст и его обсуждение по разным страницам.
ВадимБарсуков:
Нехило было бы сделать и просто разметку в тексте, позволяющую сворачивать-разворачивать размеченный фрагмент (см., например, аналог в HomeSite5). Это можно сделать на JS. Области применения как вариант примечания; в списке новостей с развертыванием более подробной информации; в разных To Do? и тэ дэ.
Маркировка страниц с разными правами
Не помечать ли страницы, недоступные для редактирования, скажем, другим цветом фона? Желтеньким, голубеньким, в цветочек.
В более общем виде предложение состоит в том, что желательна маркировка страницы в соответствии с установленными на нее правами (не обязательно цветом фона) грустно натыкаться на сообщение «Звиняйте, правов у вас нема!».
/Ку Ме: интерфейсная проблема. Переложена на темы. В теме табс например, у вас нет вкладки «редактирование», если нет на то прав, insntit?
Порог чувствительности к изменениям
Зачем сохранять версию, которая не отличается от предыдущей или отличается незначительно. Может быть в настройках diff дать возможность юзеру настраивать «порог чувствительности» diff'а (например, количество измененных знаков? Может быть, ввести и список учитываемых операций к примеру, «удаление да, редактирование нет?» Или это изврат?). Если настраивать не diff вообще, то порог для извещений точно (чтоб по всякой мелочи не беспокоили, блин :-).
VadimBarsukov В качестве полумеры: по количеству измененных знаков. Прикинем предельно грубо: небольшое изменение – это 2–3 слова, а средняя длина слова в русском языке – скажем, около 10-ти знаков. Ergo: если изменено (добавлено?) меньше 30 знаков – изменение незначительно, извещать не будем (а вообще – выбор порога чувствительности отдать на усмотрение владельца вики или пользователя).
RomanIvanov: В качестве полумеры: по количеству измененных знаков. Алгоритм simplediff вообе не знает количества изменённых знаков. Алгоритм wdiff знает, но а) часто ошибается и б) я пока не понимаю сути вашего предложения. Не сохранять, не показывать, не уведомлять или что?
VadimBarsukov: Весь сыр-бор вокруг diff'а именно потому, что больно уж diff хорошая вещь и хочется еще и еще («мне таблеток от жадности...»).
Насчет б). Именно «Не сохранять, не показывать, не уведомлять» (и даже, может быть, в будущем обнаружится еще какое-нибудь «или что». :-) Три настройки в разных комбинациях. Первые две – в основном к виковладельцу, третья – больше к викописателю.
Насчет а). Имхо, когда часто ошибается, это значит все же иногда дает правильный результат (отсекает «мусор»). Это все же лучше, наверное, чем когда постоянно приходит ненужная информация. Другое дело, стоит ли овчинка выделки.
/Ку Ме: вы правы с точностью до наоборот. Что важнее: получить 5–7 писем-исправлений опечаток или пропустить важное зачёркивание фразы в WeaselWiki:ВикиТуду или не получить извещения о поправке урла дистрибутива ваки на упаковку вирусов?
ВадимБарсуков: Наоборот, вы правы с точностью: важное пропускать нельзя. Формальный фильтр, конечно же, никогда не заменит семантического анализа. Но пока мы не умеем делать автоматической разборки текста «по смыслу», почему не воспользоваться предварительным отсевом?
А чтобы не пропустить изменения важных страниц (а ваши примеры – об этом), можно сделать настройки фильтра разными для разных категорий страниц (по важности, критичности, правам доступа). (Может, связать как-то с ACL страницы? Типа: если есть ограничения доступа, логично предпололжить бОльшую важность страницы и, следовательно, установить менее жесткий фильтр)
Большей гибкости здесь не достичь, так как минимальная самостоятельная смысловая единица в вики – страница, увы.
/Ку Ме — опять с точностью до наоборот. Если есть ограничения доступа, вероятность атаки существенно меньше (см. про рабочие группы ниже). Дайте мне ценности ошибок первого и второго рода и вероятности их возникновения? по моим оценкам получается невыгодно, хотелось бы увидеть Ваши вычисления — как можно более численные.
ВадимБарсуков Может версии разные, но у меня замочки не кажет.
RomanIvanov Концепция всех экшнов в том, чтобы (если такая настройка включена, а она по умолчанию включена) не показывать кому не нужно страниц, которые он видеть не должен. Из чего следует, что замочки в Каталоге увидеть нельзя, только ключики.
ВадимБарсуков Но в тексте (может это и не экшн) мы ведь видим ссылки на закрытые страницы? То есть существование закрытой страницы – секрет Полишинеля.
Еще вопрос: иногда кластер «закрыт на замОк», а дочерняя страница – доступна. Наследуются ли права доступа?
/Ку Ме: права доступа наследуются в момент создания. После чего страницы существуют независимо. Существование закрытой страницы, на которую нет ссылки ни с одной из открытых страниц — есть секрет, который пользователям не показывается, да. И это есть правильно.
RomanIvanov В тексте мы их видим потому что кто-то решил пренебречь [/Ку Ме: тотальной] секретностью в отношении этих страниц.
ВадимБарсуков: То есть еще более секретная страница – та, которой не существует вообще :-)
А как добираться до «закрытой страницы, на которую нет ссылки ни с одной из открытых страниц»: через адресную строку браузера или через Каталог? Правильно? А обнаружить ее существование (не имея прав) – только случайно набрав в тексте ее Вики Имя??
RomanIvanov: Это Вы сейчас глупость сказали, ага. Вот есть в данной Вики страница /Проекты?. Её название никакой коммерческой информации не раскрывает. А вот с неё есть пятьсот ссылок на наши текущие проекты, названия которых, о да, очень секретны.
VadimBarsukov: Спасибо за терпение, ага. Я вообще-то просто уточнял порядок действий владельца «закрытой страницы без ссылок на нее» :-)
Опять за рыбу деньги: снова наткнулся на {{BackLinks}}, который выводит список неких страниц (без ключей и замков). Ссылки в списке ведут на страницы, к которым у меня нет доступа... Если не ошибаюсь, это бэклинкс на странице Elena Doljenko?.
Вообще, стоило бы иметь побольше статистики: «рейтинг» посещаемости страниц, «наблюдаемости», «ссылаемости» и т.п. Можно, например, через критерии сортировки в списках страниц (типа /Каталог, /МоиСтраницы? и т.п.).
Одно из самых слабых мест wiki, imho, это навигация. Понятно, что идеология wiki ориентирована на максимально упрощенную текстовую разметку с минимумом визуализации. Противоположным примером образцом «визуального» представления гипертекста является TheBrain.
У них, кстати, есть java-апплет. В порядке бреда может интегрировать его в wiki как Визуальный Каталог? :-) или сделать каталог в стиле орг.диаграмм (такие «кубики со стрелочками»)?
Контекст для изменений
Для присылаемых извещений об изменениях было бы «зер гут» добавлять небольшой фрагмент текста, к которому были сделаны изменения.
В текстовой [plain-text] версии мэйла результаты diff идут сплошняком, т.е. если изменения произведены в нескольких местах текста, то они (изменения) приходят «слипшиеся» в один текстовый фрагмент, без перевода строки между ними. А в целом diff (да вся и wackowiki) это круто! Cool-товая вещь! :-)
/Ку Ме: это очень интересно и кажется сверхсложно.
VadimBarsukov: В JavaScript не получить напрямую доступ к списку имен? Или просто тяжело всякий раз качать его на сторону клиента? А можно через Dom брать список имен из открытой фоновой страницы с Каталогом? Или сделать плавающий iframe и подгружать в него список имен из текстового файла без обновления основной страницы?
RomanIvanov: Короче говоря, по этому пункту мы ждём вашего патча. Раз у Вас так идей много =)
ВадимБарсуков: Ага, и здесь «инициатива наказуема»! :-}
Более простой вариант выпадающий список на странице редактирования [хуже popup-окно, юзеры забанят] с перечнем Вики Имен? (т.е. типа Каталог'а).
Или (о, ужас!) отдельный фрейм для имен. Совсем хорошо drag'n'drop оттуда.
/Ку Ме: а что мешает открыть это каталог, если он нужен? =)
ВадимБарсуков Ну я и бегаю смотреть его (см. выше) :-) Но всё каких-то удобств хочется, знаете ли...
Про смайлики
Они, конечно, зло. Дай возможность, так люди будут изъясняться исключительно смайликами (см. свежий примерчик здесь). Но смайлики ответ на совершенно реальную потребность веблюдей (web-людей ;-) в средствах выражения своих эмоций посредством [каламбурчик-с!] текста (эдакая «текстовая мимика»).
Вы вот, к слову, сделали ведь в wiki смысловую разметку: ВопросЗамечание, хотя, казалось бы, текстовых/речевых средств для выражения экспрессии должно хватать?!
смысловая разметка выражает не экспрессию. Не нужно одушевлять слова.
Поэтому, имхо, смайлики конвертировать в картинки надо, но: а) ограниченный набор [:-) :-( ;-) и еще пару-тройку]; б) картинки должны быть так сказать «шрифтовые», т.е. черно-белые, выглядеть как буква (примерно так, как в MSWord при автоконвертации). Фактически это текстовый смайлик, но «повёрнутый» на 90o, чтоб шею не напрягать :-).
Можно рассматривать их как разновидность макросов (из серии
::@:: и т.п.) или как расширение набора знаков пунктуации (!, ? и иже с ними).
AlexanderNickolsky : Конвертирование смайликов в картинки это так же отвратительно, как ржание за кадром в комедиях. Смайлик хорош тем, что является составной частью текста. Пока это текст, это добавляет как бы еще одно измерение к написанному. Можно придумывать свои смайлики. Как только смайлик заменяется на картинку, он утрачивает свой смысл и становится просто картинкой. Давать возможность вообще вставлять картинку в текст – это хорошо. Давать возможность вставлять одну из 10 предопределенных идиотских картинок – плохо. Используя обычный смайлик :-) можно выразить чувства от «не обижайтесь» до «я полчаса хохотал», в зависимости от контекста. Синяя (желтая) рожа с дурацкой улыбкой выражает только одну мысль : «писавший сие – идиот».
VadimBarsukov: (О шее забочусь я, о шее...) А если серьезно, то разговор, имхо, не токмо о смайликах, будь они неладны. Речь, наверное, все же идет об открытости словаря автозамены. Тоись, бы не сделать ли в светлом будущем возможность виковладельцу (или даже викописателю) создавать свои автоподстановки. Может и макросы свои можно разрешить создавать (из имеющегося набора функций) ...
Вот я два смайла [:-) и :-(] пихаю, где только могу, а кто-то аббревиатурами балуется. Набрал, к примеру, ХЗ, а оно в ответ – ... целый абзац
Либо, в будущей Wiki Edit?(которая, по моему скромному разумению, должна заменить простую текстареа при вики-редактировании) сделать пару-тройку клавиатурных комбинаций для ввода любимых виковладельцем/юзером слов или знаков (в т.ч. смайликов). (Дались мне эти смайлики... Извините, если что, за упёрнутость :-0)
/Ку Ме: давно ходят мысли о выносе макросов на один уровень с форматтерами.
RomanIvanov всё-таки не очень понял основную мысль. Чего хочется? Вы могли бы одной максимально понятной фразой, не включающей слово «смайлик» это написать?
ВадимБарсуков: Хочется автозамены (как в MS Word, например: самостоятельно редактируемый список автозамен), либо клавиатурных комбинаций (как в Wiki Edit?, например + возможность изменять их по своему разумению) – можно и то и другое вместе.
Это одной фразой и без смайликов :-). А теперь – «философия»: есть, имхо, нечто общее между смайликами, автозаменами, клавиатурными комбинациями и макросами. Общее – скорость. Мы пишем смайлики во многом по той же причине, по которой применяем всякого рода сленговые сокращения (типа IMHO, RTFM и т.п.). Вместо того, чтобы хорошим литературным языком описать свои эмоции, рисуешь «рожу» (их недаром еще по-умному называют «эмотиконсами»). Деградация к иероглифам, конечно, но... Эпоха раннего dial-up'а, знаете ли.
Более того, сдается мне, что сама концепция вики есть порождение культа скорости: «правило двух знаков», Вики Имена?, экшенс вместо сложной хтмл-разметки, редактирование на ходу и т.п. Все это к тому, что вполне в «духе вики» двигаться в сторону развитой системы автозамен, макросов и форматтеров.
А! Да, чуть не забыл! И смайлики, конечно! :-)
RomanIvanov Кто сможет редактировать списки автозамены?
AlexanderNickolsky : Я вот еще немного своего ИМХО добавлю. Нет смысла переносить в Вики всю функциональность HTML. Для этого есть HTML. Причем в HTML сразу видно – слово какое-то в угловых скобочках и параметр=значение – значит это тег. Пусть я его не знаю, но я знаю, что данное заклинание относится к форматированию текста и само как есть показано не будет. В Вике, особенно в части макросов, ничего априори не понятно. Если количество макросов увеличить сверх 5–7 штук, то юзеры начнут их вводить случайно. И будут долго удивляться результатам :-) Быстро – это хорошо. Но надо еще чтобы было просто. Тогда только будет быстро.
VadimBarsukov: 2AlexanderNickolsky. C обоими принципами («Вики != HTML» и «просто = быстро») не спорю. Но вся фишка в том, что простота у каждого из нас своя. Кому-то проще опознавать хтмл-теги в тексте, а кто-то запомнил правило «двух знаков» и запросто отличает разметку [((, **, {{ и т.п.] от содержания. Более того, критерии простоты у нас меняются со временем – мы обучаемся, привыкаем. Что казалось непростым и длительным – доводится до автоматизма. Отсюда, имхо – вывод: программа (среда) должна предоставлять нам возможность расти – от более простого к менее простому :-) 2RomanIvanov. Отсюда же вытекает и следствие: хорошо бы, если б списки автозамены могли редактировать как викиадмины (базовый набор, действует на всех), так и викиюзеры (автозамены действуют только в его сессии). [Отдельно можно подумать над тем, могут ли юзверские настройки перекрывать админские] Гордый ламер будет юзать 5–7 базовых, а переродится в скромного кулхацкера – нарисует свои.
И будет тогда и НАМХО и ИМХО :-)
/Ку Ме: Unknown action "a="outprog""используйте софт на клиенте. Тысячи программ на любой вкус. Я пользуюсь KeyText2000 например, вот для <table cellspacing="0" cellpadding="0" border="0" width="100%"> этого, или для <img src="/z.gif" width="1" height="1" alt="" border="0" /> этого иногда.
RomanIvanov: Кусо – горячий японский парень. Почему на клиенте? Предлагаю сперва обсудить-таки целесообразность внедрения этого в викиэдит или ваку.
VadimBarsukov2КуМе Совет хороший, но зачем Вы тогда вообще используете в вики макросы, а не KeyText2000, например? Комплексом сторонних программ, наверное, можно заменить всю функциональность вики.
Частность, но, имхо, в тему: у меня в клиенте (My IE?) на Alt-L висит вызов списка ссылок на текущей странице, поэтому Alt-L в Wiki Edit? перехватывается. Отсюда желание иметь возможность переназначать клавитурные комбинации в Wiki Edit?.
/Ку Ме: я не использую в вике макросы. Не нужно делать из вики швейцарский армейский нож.
ВадимБарсуков: Конечно, я не имею в виду лично Вас. Речь о том, что иначе не надо было и макросы внедрять в вику, раз есть другие способы делать это.
А в каком-то смысле любая действительно хорошая программа – швейцарский нож, ибо объединяет в себе те орудия, которые нужны для удобного и эффективного выполнения своих задач, не так ли? Важно понять, что действительно нужно, что избыточно, имхо. Этим мы вроде бы и занимаемся сейчас, я так полагаю. Поправьте, если что...
/Ку Ме: хорошая программа — это Leatherman, если вы понимаете о чём я =). А чтобы понять, что избыточно, нужно понять, что надо. И зачем.
В процедуре /Registration (кстати, почему не Registrazija?) упоминается страница Имя Фамилия?. Она жестко ссылается на соответствующую страницу /Wacko Wiki, а не текущей инсталляции /Wacko Wiki :-(
Хорошо бы знать, кто тебе отвечает (внес исправление) (diff-то покажет, но его ведь надо специально смотреть). Либо опцией «Всегда указывать автора исправления» (как предлагалось в To Do?), либо сделать на измененный фрагмент разметку типа <span_title="Вики Имя?">измененный текст</span>. Подвел (только в IE?) мышу к изменению и получи tips с Вики Именем? (а то и датой).
RomanIvanov Дело в том, что неглючащего диффа не бывает. Так что не выйдет.
VadimBarsukov: Мда, возможно тут и не столько «дело техники» (т.е. как это реализовать технически). Похоже это попытка ввести концепцию не только владельца страницы, но владельца текстового фрагмента, что, скорее всего, избыточно. Но заманчиво...
ВадимБарсуков: Ну вот, навскидку: а) знать, кто отвечает (если нет подписи); б) фильтр по приоритетам (например, извещать об изменениях от Иванова :-), а от Петрова – не извещать); в) авторизация (например, сейчас в обсуждении можно выступать под чужим именем – не полезут же читатели каждый раз в diff, чтоб узнать кто автор высказывания); г) режим автоматического извещения автора, если кто-то меняет «его фрагмент» и т.п.
RomanIvanov Звучит всё очень заманчиво, но совершенно несбыточно =(((
VadimBarsukov: Избыточно – заманчиво – несбыточно. Что ж – будем ждать R5 или R10. To Do Для R 10?: в принципе, чтоб запомнить фрагмент, достаточно 3-х чисел: ID автора, сдвиг с начала текста, длина фрагмента. Есть закладурка, которая выделяет в тексте страницы искомый текст. Может быть, аналогичным образом выделять JS-том необходимый фрагмент по запросу юзверя?
/Ку Ме: а — оповещения по почте, использование WeaselWiki:ВикиПаттерны/ВикиРефакторинг + WeaselWiki:ВикиПаттерны/ВикиДискуссия, б — не имеет отношения к обсуждаемой проблеме, оффтопик, в — проблемы культуры дискуссии. Лично мне не интересно работать в одной группе с человеком, который иногда выступает «не от своего имени», поскольку целевое применение WeaselWiki:ВикиПаттерны/ВикиДискуссия — рабочая группа, то этот момент кажется мне излишним. г — решается переносом ключевых фрагментов в include. Итого — пока вики работает с текстом, а не с XML — бесполезная и громоздкая эвристика, которая к тому же ещё и ошибается.
VadimBarsukov: В целом с Вашим выводом согласен (особенно с идеей об XMLвике: работать с логической структурой текста), но отнёс бы его к нынешней реализации вики, а не к её концепции вообще.
Соответственно, и Ваши замечания по пп. а) — г). также сводятся к тезису «комбинируй существующие возможности» (см. также Ваше предложение об использовании сторонних программ), против которого возразить, в принципе, нечего. Будет или не будет реализована какая-либо новая фича (заменяющая прежнюю комбинацию действий), зависит от степени её востребованности вики-сообществом (т.е. оттого, насколько «горяча» потребность в ней).
По пункту в) могу уточнить, что (обычно) это своеобразная «рабочая группа» – открытая и с возможностью неавторизованного участия (почти как «клуб анонимного секса» :-) со всеми вытекающими. Свести вики к строго ограниченному участию, имхо – превратить ее просто в CMS.
/Ку Ме: общение в таком клубе «анонимного сердца», построенном на отсутствии принципов взаимного доверия, безрезультатно. Безрезультатное общение в вике меня не интересует. А чем, кстати, вики не CMS.
/Ку Ме: и, наконец, самое важное. Если начать цеплять авторство к каждому абзацу, каждому слову — потеряется сама соль совместного авторства. Которое и является одной из наибольших ценностей привнесённых вики.
Имхо, с регистрацией на вики надо немного помудрить. Сейчас ничего не стоит зарегистрироваться, указав «вражеский» email, затем, скажем, наставить «наблюдаю» на страницах (или просто на одной, которую нещадно править большими объемами текста :-). Получается, этакий почтовый анонимайзер (гусары, молчать! :-).
Надо хоть подтверждение на почту или пароль почтой.
На страницах, уже имеющихся в личном меню, «крестик» «Добавить в личное меню» убрать нафиг или «засерить» (т.е. сделать серым, неактивным :). А то пуще того, сделать вместо него «минус» «Убрать из личного меню».
К вопросу и замечанию не добавить ли примечание (дополнительные, не прямо относящиеся к тексту замечания)? Оформить по типу примечание, только без перечеркивания. Или уменьшенным кеглем. Мне вот не хватает, откажете буду пользоваться моноширинкой :-).
AlekseyKulakov мне, кстати, тоже не хватает. Отличается тем что замечание более активно чем текст а примечание менее.
VadimBarsukov: Замечание требует, чтобы его заметили, посему выделяется пестрым окрасом. Примечание же, будучи сущностию скромною, прикрывается мышастым колером или малым размером своим, дабы не отвлекать драгоценного внимания читателя от биения основной мысли. Примечание оно при этой мысли.
/Ку Ме: есть некоторый смысл, согласен. Также смотрю в сторону футнот. Не кажутся ли они более удобным вариантом примечания?
ВадимБарсуков: Футноты вариант интересный, но а) в дополнение к «потоковому» примечанию; б) с автоматической генерацией обратной ссылки (типа «Назад к тексту»).
Можно пофантазировать также о вариантах примечаний в виде tooltips (с длительным временем показа), в виде бегущей строки в строке статуса браузера (неудобно), в виде заметки «на полях» страницы (реализация через <DIV> наверное), в виде меню, выползающего из-за края экрана (dHTML) и о прочей экзотике. Я вам еще не надоел? :-)
ВадимБарсуков: Вот еще вариант оформления примечаний фрагмент текста, который по умолчанию свернут, а при необходимости нажатием «кнопки» (пиктограммки, «звездочки»-ссылки и т.п.) раскрывается. См. также здесь.