>>27811
> (без переносов строки)
Одну-две строчки в parse.class.php поменять.
> добавить какой-нибудь [code][/code] с подсветкой синтаксиса как в /g/ «4чана»
Dunno.

https://codeberg.org/FBE410/fbe-410/issues/48
Скрытие нитей через каталог. А то на «Ычане» есть, а у нас нет.

Думаю ещё над заменой индикатора сажи. Чтобы вместо сомнительно выглядящего засовывания стрелки в тему прикреплять к сообщению значок в формате СВГ. С другой стороны, а нужен ли вообще индикатор сажи? А то из возможности просто не поднимать нить (по любым причинам) получается какой-то эрзац-дислайк.

Немного менѣе 4⅚ года назад (то есть в феврале 2020 г.) мы разсмотрѣли по адресу https://410chan.org/dev/arch/res/20450.html#24001 вопрос о том, полезно ли использовать появившийся тогда в Mozilla Firefox (а до того и в Google Chrome) механизм, позволявший подзадержать полную загрузку страницы для экономии траффика, а именно откладывать момент начала скачивания миниатюр (thumbnails) до прокрутки страницы к ним.

Тогда эта идея была отвергнута в интересах пассажиров метро (и вообще всѣхъ пользователей нестабильнаго Интернета, желающих сперва скачать страницу цѣликомъ, а затѣмъ читать её со всѣми миниатюрами в вынужденном оффлайне).

Сейчас предлагаю разсмотрѣть болѣе новый, но также ужé изрядно давно существующий механизм обмѣна в диаметрально противоположном направлении (то есть такой механизм, которым обмѣнивается не скорость на траффик, а как раз наоборот — траффик на скорость), который позволяет немного ускорить загрузку страниц за счёт того, что начинать их предзагрузку ещё до перехода по гиперссылкам, то есть не тогда, когда гиперссылка окажется жмякнутою, а чуть раньше — когда палец надавил на гиперссылку (но ещё не отпустил её) на сенсорном экране, или когда кнопка мыши ужé нажата (но ещё не отпущена) на гиперссылке, или когда мышь была наведена на гиперссылку на 200 миллисекунд (или дольше), но в каждом из этих случаев рост наблюдаемой скорости открытия страниц (за счёт предзагрузки их) обмѣнивается на дополнительный расход траффика в том смысле, что сёрвер ужé отдал страницу, а пользователь мог и передумать на неё заходить (и тогда траффик был израсходован зря) в трёх частных случаях:

➊ Пользователь мог жмякнуть пальцем по гиперссылке не для перехода по ней (краткое нажатие), а для вызова контекстного меню (долгое нажатие), но это не извѣстно тогда, когда он ещё только надавил пальцем.

➋ Пользователь мог жмякнуть мышóю по гиперссылке не для перехода по ней (краткое нажатие), а намѣреваясь drag-and-droпнуть гиперссылку, но это не извѣстно тогда, когда он ещё только надавил пальцем на кнопку.

➌ Пользователь мог задержать указатель мыши на гиперссылке для предпросмотра (410чан показывает сообщение при наведении на гиперссылку) без намерения перейти по гиперссылке, чтобы открыть всю страницу. А зачѣмъ ему открыть всю страницу? — ну, напримѣръ, чтобы открыть спойлеры (при предпросмотре не видные), или чтобы погрузиться в контекст обмѣна репликами вокруг сообщения, им увиденного.

Этот механизм называется Speculation Rules API и существует единственно во хромоподобных браузерах (то есть в Google Chrome, в Microsoft Edge, в Opera и проч.). На сайте «Can I use…» пишут, что механизм этот начал появляться с августа 2022 года, а свою теперешнюю форму (с необязательностью параметра «source») приобрёл с конца февраля нынѣшняго (2024) года, так что её поддержка достигла уровня 70,12% от общего числа браузеров теперича.

(По адресу https://caniuse.com/mdn-html_elements_script_type_speculationrules можно посмотрѣть на первую из этих двух дат, а по адресу https://caniuse.com/mdn-html_elements_script_type_speculationrules_source_optional на вторую.)

Конкретно можно было бы для начала добавить на каждую страницу такой скрипт:

<script type=speculationrules>
{ "prerender": [
   {
      "eagerness": "conservative",
      "where": { "href_matches": "/:board/res/(\\d+).html#(i?\\d+)" }
   },
   {
      "eagerness": "moderate",
      "where": {
         "and": [
            { "href_matches": "/:board/res/(\\d+([+-]\\d+)?).html" },
            { "not": { "href_matches": "/:board/res/(\\d+).html#(i?\\d+)" } }
         ]
      }
   }
] }
</script>

Гиперссылки для дальнѣйшаго чтенія про эту фичу прилагаю:

① Общий обзор: https://developer.chrome.com/docs/web-platform/prerender-pages

② Обзор записи правил: https://developer.chrome.com/blog/speculation-rules-improvements

③ Документация по API: https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API

④ Документация по записи скрипта: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/speculationrules

⑤ Документация по записи шаблона URL-адресов: https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API

>>27820
Мало того, что оно не во всех движках, так ещё и трафик жрёт? Я думаю, это отказ.

Чувствую неопредѣлённость.

Раньше у нас не было поддержки AVIF во браузерах — теперь она у нас есть во всѣхъ новых версиях всѣхъ сколько-нибудь популярных браузеров вот ужé дольше десятка мѣсяцевъ.

Раньше у нас не было поддержки AVIF в PHP — теперь она у нас есть.

Раньше у нас не было поддержки AVIF гуглолинзою поиска по картинкам в Интернете — теперь она у нас есть.

Раньше у нас не было пуллреквеста с готовым кодом для поддержки AVIF в FBE — теперь он у нас есть.

Поэтому думаю: да есть ли нѣкоторое опредѣлённое препятствие, которым ещё сдерживается обеспéчение возможности выкладывать AVIF на 410чан (но тогда почему для поддержки WebP такого препятствия вроде б не было), или есть только неопредѣлённое чувство недостаточности спроса («ну очень не хочется наливать воду в сухой бассейн, потому что год за годом видно, что в нём никто не торопится прыгать с вышки», «ну очень не хочется строить мост через крупную рѣчку въ этомъ мѣстѣ, потому что меньше десятка автомашин в год пытаются попасть вброд на тот берег именно здѣсь» и проч.)?

>>27817
Видимо, всем плевать на индикатор сажи.

Поотвечать/запиливать пока руки не доходят.

>>27817
Почему бы и да. Надо будет сделать отдельный столбец в posts_$boardname.

> получается какой-то эрзац-дислайк.
А мы точно хотим лишить людей уже, наверное, традиционной возможности выразить своё недовольство таким образом? Но чисто лично я не сильно против отмены индикатора, хотя на наших скоростях сажу всё равно можно будет иногда, а то и чаще, заметить, и посчитать downvote-ом.

Закончилася поддержка Theora во браузерах: https://caniuse.com/ogv

Не отпилить ли её и здѣсь?

Думаю в качестве значка сажи использовать шалфей, лол. Пока как-то так.

>>27829
Можно. Я так понимаю, с точки зрения расширения «Ѳеора» = ОГВ, и нам уже сейчас следует убрать его из разрешённых к загрузке?

>>27831

Да.

Ужé послѣ того, как загрузка перестанет быть разрѣшённою, можно будет и из кода FBE выкинуть строчку специальной обработки таких загрузок («if( $expectedFormat === 'ogv' ) $expectedFormat = 'ogg';»).

>>27831
Как-то с шалфеем вы меня потеряли, в чем суть?

>>27833
Sage (сажа) — не только мудрец, но и растение.
https://www.nccih.nih.gov/health/sage

>>27833
А ведь обо всём написано здесь:
https://noobtype.ru/wiki/Sage

>>27836
Читайте и тщательно конспектируйте Нубтайп...

Завёл задачу про значок сажи:
https://codeberg.org/FBE410/fbe-410/issues/51

Файл приложен сюда, но следует преобразовать его, как описано здесь: https://codeberg.org/FBE410/fbe-410/src/branch/public/icons

На мобилке, может, вернуть старый размер шрифта для topmenu? У меня не влезает и не красиво. A52.

>>27842
Скукожили обратно.

>>27842
Алсо, смотрю я на этот скрин с формой постинга на весь экран, и думается, а не стоит ли нам сделать сворачивание формы создания нити как на «4чане»?

>>27847
Мне кажется как минимум ради мобилок стоило бы, чтобы сразу было видно топ-нить и не надо было пролистывать

>>27851
Но верхнюю нить (начало её) и так сразу видно.
>>27847
Не на весь.

>>27852
Да всё равно, на пол-экрана форма что на мобилках, что на ПК.

>>27543

> Давайте обсудим, как эта лабуда должна себя вести.

Предлагаю, окромя счётчиков слѣва (у букв досок), помѣстить ещё один счётик справа (у кнопки «Главная»), который бы показывал наличие новостей на главной, а то они ж теперь нифигушеньки не появляются сообщениями на доске d/ (потому что >>/d/3126).

В общем, добавил задачу на сворачивание формы постинга: https://codeberg.org/FBE410/fbe-410/issues/54

Хотя последнее время желающих ковырять движок не видно, похоже.

Год.

Цѣлый год каждая новая версия каждого сколько-нибудь популярнаго web-браузера выходит с поддержкою AVIF, но 410чан остаётся без оной.

>>27793
>>27794
Сделано. Счётчик отображается, если набранное наполовину подобралось к ограничению по длине. При превышении ограничения, кнопка отправить не disable'ится, но по клику на неё показывается сообщение о превышении без его отправки на сервер. Стилеспецифичный CSS не делал.

Побочка. Надо будет перегенерировать страницы. Поскольку максимальная длина для скрипта передаётся ему через template, их надо будет перегенерировать при любом её изменении в настройках доски. Так что по-хорошему это надо бы не в template-ы, а во что-то наподобие https://a.4cdn.org/boards.json, которое перед отправкой сообщения читать и проверять его длину и другие параметры на соответствие.

Но такой JSON, наверное, потом вместе с улучшением фоновой проверки в целом стоит запилить. Запилив, скажем >>27485. Ещё, сейчас отправка идёт через fetch, но если сделать через XMLHttpRequest, можно будет вместо Отправка... отображать Отправлено 78%.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>27873
Судя по всему, не работает и продолжает проверять размер в байтах.

>>27875
Странно, УМВР. Новый posting.class.php точно был скопирован?

Аа, вижу. На 122-ой там забыл strlen на mb_strlen поменять.
> exitWithErrorPage(sprintf(_gettext('Sorry, your message is too long. Message length: %d, maximum allowed length: %d'), mb_strlen($_POST['message']), $board_class->board_messagelength));
Но всё равно странно. До exitWithErrorPage оно не должно было дойти: условие в if-е верное.

Судя по всему, проблема в том, что internal_encoding у PHP на сервере, где производилась проверка, стоит не UTF-8.

Стало быть, проблема решается либо редактированием php.ini и перезапуском Apache, либо указанием для mb_stlen кодировки: заменить mb_strlen($_POST['message']) в posting.class.php/CheckMessageLength() на mb_strlen($_POST['message'], 'UTF-8').

С этим posting.class.php сейчас должно работать, но по-хорошему стоит посмотреть, что в настройках сервера.

>>27883
Да, это работает, но, судя по всему, оно включает имя файла в длину сообщения.

Так как идея https://codeberg.org/FBE410/fbe-410/issues/41 состояла в том, чтобы сосчитать сѵмволы (а не двухбайтовики UTF-16), то свойство «.length» в джаваскрипте не годится в диапазоне U+010000…U+10FFFF (то есть для многих эмоджи — напримѣръ, сѵмволъ «🕸️» состоит из кодов U+1F578 и U+FE0F), а считать придётся как-нибудь так:

const countCharacters = textStr => {
   var strLen = textStr.length;
   if( strLen < 1 ) return 0;

   var total = 0;
   var curr = 0;
   var code;
   while( curr < strLen ){
      code = textStr.codePointAt(curr);
      if( typeof code == 'number' ){
         total++;

         if( code < 0x10000 ){ // Basic Multilingual Plane
            curr++;
         } else curr += 2; // UTF-16 surrogate pair
      } else return total;
   }
   return total;
};

>>27890
Спасибо, исправил.
> cостоит из кодов U+1F578 и U+FE0F
Но разве для кодирования '🕸' не достаточно одного UTF-16 символа, пусть и из двух юнитов?
https://www.compart.com/en/unicode/U+1F578

Также учёл конвертацию "\n" в "\n\r" браузером при отправке.

Видимо, действительно не достаточно: в >>27891 паутинка отображается только на десктопе, а в >>27890 и на мобилке, тоже.

>>27891

> Также учёл конвертацию «\n» в «\n\r» браузером при отправке.

Лучше всего было бы не наращивать счётчик на 2 при каждом переводе строки, а замѣнять «\r\n» на сёрверной стороне единичным «\n» перед подсчётом числа сѵмволовъ.

Основание этой мысли вижу в том, что формат «\r\n» свойственен системе Windows, тогда как пользователи системы macOS или Linux (а также Android, FreeBSD и проч.) ничѣмъ двухсѵмвольную оцѣнку перевода строки не заслужили — но тогда и пользователей системы Windows проще перетащить на тот же уровень во имя единообразия.

>>27894
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data
Формат свойствен стандарту: endl при отправке — это "\r\n". Безотносительно системы.

Тоже думал решить эту особенность на сервере, но всё-таки решил на клиенте, чтобы сервер делал проверку по и возвращал ровно то количество UTF-8 символов сообщения, которое туда приходит, без подвохов.

Могу сделать проверку с mb_strlen() - substr_count($_POST['message'], "\r\n"), перенос строки при проверке будет считаться за один символ, если Соус того желает. Если нет, то можно обновить lib/javascript/kusaba.js файлом из >>27891, и подсчёт должен работать корректно.

С одной стороны, технически возражение >>27896 совершенно справедливо.

С другой стороны, его воплощение противорѣчило бы привычному поведению счётчиков на других имиджбордах.

В настоящее время всегда видимый счётчик на Абучане считает перенос строки единичным байтом.

Не всегда видимый счётчик на Форчане (становящийся видимым на красном фоне при превышении лимита, равного 2000 байтов на большинстве досок — однако на досках jp/ и vt/ это 5000 байтов, а на досках lit/ и mlp/ и qst/ это 3000 байтов, как нам содержимое файла https://a.4cdn.org/boards.json подсказывает) также считает перенос строки единичным байтом.

На всякий случай тотчас же поясню, что насчёт этих двух имиджбордовых счётчиков я пишу о байтах (а не о сѵмволахъ) по той причине, что тот и другой имиджборд наращивает счётчик на двойку для сѵмвола «ы» (слѣдовательно, считает его как байты 0xD1 0x8B кодировки UTF-8) и на семёрку для сѵмвола «🕸️» (слѣдовательно, считает его как байты 0xF0 0x9F 0x95 0xB8 0xEF 0xB8 0x8F кодировки UTF-8).

Поэтому возможны контраргументы такого рода:

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

— Если двухсѵмвольный подсчёт переноса строки непривычен при сравнении с другими имиджбордами, то ужъ тѣмъ болѣе непривычен небайтовый подсчёт сѵмволовъ, так что чего уж теперь стремиться к привычности.

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

Насколько эти контраргументы убедительны, умѣстно ли руководиться ими?

Для оцѣнки распространённости явления я дополнительно сообщаю, что и Twitter (нынѣ 𝕏), и Telegram, и даже порносайт https://pornolab.net/ наращивают свои счётчики на единицу при подсчёте перехода на новую строку.

>>27896
>если Соус того желает
Меня больше вот эта проблема интересует сейчас: >>27884

>>27900
Так там не в имени файла дело же оказалось.

>>27901
Да? Я не могу попробовать новую версию скрипта пока, но вы тут пишете про какие-то четырёхбайтовые эмодзи и переносы, в то время как в >>27884 оно при проверке считает имя файла в суммарную длину сообщения (и без файла даёт запостить). Как это связано, лол?

Пока не забыл, ещё вопросы насчёт функции «setup_message_length_indicators» в коде >>27891:

➊ Какой смысл добавлять к счётчику нули слѣва?

➋ Почему счётчик должен быть трёхразрядным (напримѣръ, «001/1000»), если считает до тыщщи, но четырёхразрядным (напримѣръ, «0001/8192»), когда считает до всякого другого четырёхразрядного числа? Не проще ли и не короче ли было бы вмѣсто «Math.ceil(Math.log10(max_message_length))» использовать выражение «('' + max_message_length).length», результат которого не создаёт этого нюанса? А не то сбивает с толку намёком на то, что считает только до 999, а не до тыщщи — однако условие «c_len > max_message_length» в функции «check_post» говорит нам, что до max_message_length всё же можно досчитывать.

➌ Точно ли нужно создавать и наполнять свойство «msg_area.last_msg_len» для того, чтобы не вызывать присваивание «indicator.textContent = ''» лишний раз? (Сильно ли тормозит?)

>>27902

Длина строки «[Doremi].Chuunibyou.demo.Koi.ga.Shitai!.Movie.Take.On.Me.[1920x1080].[Blu-ray].[2BB3C549].mkv_snapshot_00.25.07_[2018.07.27_23.17.43].jpg» равна 137 сѵмволовъ и оттого подозрительно не похожа на разницу между величинами 8257 и 8192 наверху скриншота >>27884, которая равна 65.

Зато разница >>27905 превосходно равняется количеству концов строк в тексте, состоящем из 66 строк (между которыми 65 концов, раздѣляющихъ строки между собою) — а вѣдь прямо сейчас в вики-коде https://noobtype.ru/w/?title=Ычан&action=edit&section=1 (ещё ни разу не перемѣнявшемся въ нынѣшнемъ году) можно насчитать как раз 64 строки, если первою считать заголовок «== История ==», а послѣднею — строку «Среди нововведений 2009 года можно назвать начало сотрудничества с другими имиджбордами по добавлению их досок во фрейм «Ычана».», которая видна на скриншоте >>>>27884 одной из послѣднихъ и позволяет нам угадывать источник используемой копипасты. И за нею (дополняя до 66 строк) видны ещё строки «2010—2011» и «рпопопо…».

Вот поэтому-то мы и разсуждаемъ о том, как правильно считать сѵмвол (или два сѵмвола) конца строки.

>>27906
> gettext('Sorry, your message is too long
Встречается только в posting.class.php и только единожды — в CheckMessageLength.
> CheckMessageLength(
Вызов этой функции встречается только в board.php и тоже только один раз.

Можно было бы предположить, что где-то до выполнения CheckMessageLength при наличии файла выполняется $_POST['message'] = str_replace("\r\n", "\n", $_POST['message'])), но у меня такого нет: есть файл, нет файла, а сервер возвращает ту же длину. Так что…

>>27902
> Как это связано, лол?
Не знаю.
> (и без файла даёт запостить)
Can not reproduce. Воспроизводился неправильный подсчёт клиентом UTF-8 длины would-be отправляемого сообщения, что в новой версии kusaba.js и починил.

>>27903
➊ Так в >>27794 нарисовано было;
➋ Починил;
➌ Не нужно. Последил за htop, когда setup_message_length_indicators закоментированно и когда нет, на 100000 символов разница в нагрузке особо не заметна. С другой стороны, лишний раз textContent менять не нужно, either, так что оставил.

>>27908

> Так в >>27794 нарисовано было

Это соображение совершенно справедливо.

(Впрочем, если им послѣдовательно руководиться, то тогда и счётчику слѣдовало бы считать от 0000, а не от полумаксимума.)

Дополнительно сообщаю о двух возможностях упрощения:

① запись «'/' + String(max_message_length)» можно упростить до «'/' + max_message_length»,

② запись «msg_area.oninput = (e) => {» можно упростить до «msg_area.oninput = () => {».

В общем, по главной предлагаю пока сделать как на картинке.
Если потом нарешаем какие-то декоративные штуки прикрутить, можно будет уже отдельно обсуждать.

Ещё надо добавить <meta name="viewport" content="width=device-width,initial-scale=1"> на news.php и её подстраницы, чтобы мобилочная ЦСС работала.