А что, sarcastic cat таки забил на перепиливание движка?

>>15851
Если бы кто-то чем-то занимался, то этого треда бы не было.

>Скрытие тредов
Скрытие тредов сделать будет проще всего. Собственно, это можно реализовать как на 410м, добавить плашку-плейсхолдер для скрытых тредов, и кнопочку скрытия. Для браузеров у которых нет локалстореджа можно сделать фоллбек на куки.

>Большие картинки должны разворачиваться не в натуральную величину, а с учётом ширины и высоты окна.
Тут придётся выбрать, по ширине или по высоте. Не скукоживать же макрос до высоты окна смартфона, например. Но в целом, если не будет стилевых конфликтов это ограничение возможно сделать css-средствами. Если, конечно, нет ограничений по версии CSS. И тут подходим к главному:

Вы не назвали целевые браузеры для отображения. Базово, насколько олдскульно всё нужно сделать? Потому что мне кажется, что текущий ычан можно вообще открывать на чем угодно и использовать без яваскрипта, например. Т.е. хотелось бы понять, к насколько старым версиям JS и CSS мы стремимся

>>15854
Куки не хотят, чтобы не раздувать оные куки всякой лабудой.
Браузеры актуальные, костыли для всякого старья не нужны. Просто с отключенными/неподдерживаемыми скриптами оно должно работать как работает сейчас.
В чём проблема скукоживать на смартфоне? Там всё равно будет удобнее в новой вкладке открыть.

>>15855
>Просто с отключенными/неподдерживаемыми скриптами оно должно работать как работает сейчас.
Т.е. я правильно понимаю, что хочется вообще никаких изменений в вёрстку не вносить, и необходимые элементы интерфейса тоже добавлять скриптами?

>В чём проблема скукоживать на смартфоне?
Читать будет неудобно же. Это сейчас для смартфона всё классно, нажал - открылась картинка в новой вкладке. А с этим скриптом - уже нет, будет подгоняться прямо в текущем DOM под экран. Ну, если не делать специально чтобы на смарфтонах всё было по-старому.

>>15856
>Т.е. я правильно понимаю, что хочется вообще никаких изменений в вёрстку не вносить, и необходимые элементы интерфейса тоже добавлять скриптами?
Что-то уровня кнопок скрытия можно добавить. Главное, чтобы эти не мешали пользоваться сайтом тем, у кого это не работает. По-моему, это самоочевидно.
Если можно разворачивалку картинок на мелких экранах подавить, то лучше подавить.

>>15857
Ок, I'll see what I can do.
Если что, запощу предлагаемое решение прямо сюда.

Полчаса в блокноте http://pastebin.com/qdDGcMjB

>>15859
Ну и картинки http://pastebin.com/1M1TE13U

Родное скрытие тредов? Вот это поворот.

>>15861
Это будет не нативное скрытие, а лабуда какая-то. Нативное скрытие — это когда сервер отправляет тебе только нескрытые треды для отображения на нулевой, динамически формируя эту самую нулевую для каждой сессии. Здесь же предлагается решить всё на стороне браузера. Нет, для тех, кто не использует сторонние юзерскрипты, это будет лучше, чем ничего, конечно...

>>15862
Для тех кто не использует? Лол. После выше описанной ситуации те кто не использует начнут использовать принудительно скрипты же. И единственный способ отключить их будет в отключении JS на корню. Особенно если все функции в один файл запихают.

>>15850

Альтернативное решение, написанное более старо и с некоторыми проверками. В отличие от предыдущего автора требует впиливание в вёрстку.

В хедер нужно добавить сам скрипт:

<script type="text/javascript" src="rm_files/iithread.js"></script>

Потом нужно добавить перед каждым div с тредом плейсхолдер:

<div id="thread-placeholder-73380" style="display:none;">Тред <a href="http://iichan.hk/rm/res/73380.html">73380</a> скрыт. &nbsp; [<a href="#" onclick="javascript:iiexpandthread('rm', 73380); return false;">Раскрыть</a>]</a><br/></div>

В каждом треде нужно добавить кнопку скрытия после кнопки [Ответ]

 &nbsp; [<a href="#" onclick="javascript:iicollapsethread('rm', 73380); return false;">Скрыть</a>]

В конце страницы добавить вызов убирания ранее скрытых тредов (для повторных заходов и перезагрузок страницы):

<script type="text/javascript">iicollapseuserhiddenthreads('rm')</script>

Зипрелейтед - сохраненная страничка с уже вставленным всем, в качестве примера того как это работает.

>>15864
Вместо 'rm' и 73380 подставляются имя доски и номер треда соответственно.

>>15854
Через стили можно реализовать всё, кроме запоминания скрытия. У кого работать не будет, у того просто не будет работать. Но без запоминания теряется смысл. А вообще >>15862 господин прав, и в /d/ ычана всё это много раз обсуждалось. Всё что не на сервере = костыли, а в данном случае ещё и костыли принудительно вставленные. И так уже гуглозонд нам вставили. Выбора пользователю никто не даёт. Сейчас конечно модно всё за других людей решать. Но по человечески эгоистично всё это. Лучше дайте нормальный инструмент по подключению всех этих функций к браузеру для технически не подкованных людей. Хотя бы однокнопочный однострочный скрипт по подключению куклы. А то армейским способом кусабите. Ссылки на куклу во фрейме нет? Каталога браузерных расширений там же нет? Конструктора расширенного функционала нет? Нативной серверной поддержки нет? Зато будем принуждать всех парсить жабокостылями сраницы. Потому что новички тупые и им лень. Да любому нормальному человеку будет лень, если он не гик-линуксоид. Но это же не повод в самом деле!

>>15862
>>15866
Напишите сначала нормальный движок с динамическими страницами, а потом будете продвигать ваши блестящие идеи.

>>15867
Блестящая идея заключается в том чтобы дать людям выбор. А то меняете мыло на шило. Даже хуже. Раньше скриптов почти не было, но их можно было основательно погугля найти и подключить. Теперь всё будет включено как в метроотеле, опять же принудительно, а на выбор только отключить JS. Зачем обязательно впадать в крайности и устраивать из их выбора драму? Я не понимаю. Кому надо - тот подключит. Хотите помочь им? Положите на видное место и упростите процесс. Нет же, нужно тех кого всё устраивает упрекать в том что они не пилят новый движок, а тех кому нужен падающий снег и webm что не могут сидеть на голой вакабе. Всё через садо-мазо, чесслово.

Банально куклу прикрутите через .innerHTML = и повесьте бинарный переключатель на кнопку. Я не знаю что может быть проще ссылок во фрейме и кнопки делающей звездато.

Я бы может и раз запилить движок для АИБ и давно сам мечтаю. И опыт у меня есть, аж по написанию движка для полноценного форума... правда он накрылся недописанный вместе с хардом больше 10 ле назад. Но только меня всё устраивает и даже после отключения JS будет по большому счёту устраивать, а время незаметно всё куда то уходит, уходит и кажется что даже от части на пользу Ычану, а мир всё так же катится по маршруту автобуса. И логика в нём.

>>15868
> Блестящая идея
Блестящая она конечно потому, что твоя.

>>15867
Котоба жи!

>>15869
Не понял сарказма. Мой был в том чтобы назвать "блестящей идеей" что то из очевидного и извечного. Если право выбора было твоей идеей, я не против, коперайти.

>>15867
https://github.com/ololoepepe/ololord
https://github.com/ololoepepe/ololord.js
https://github.com/rngnrs/tumbach

>>15874
Страницы не динамические, алло. И не могут они быть динамическими при хоть сколько-то заметной посещаемости, разоришься на серверах каждый раз рендерить их.

>>15875
Тогда го в твиттер, максимум динамики и кто-то умудряется в его убыточность до сих пор инвестировать.

>>15876
Попробуй его без JavaScript открыть для начала. Там на стороне клиента делается ВСЕ, что только можно, и это правильно.

>>15877
Всё, кроме собственно генерирования уникальной ленты для каждого юзера, его уведомлений, меншенов, а также листов. Потому он и лёг во время одного из оскаров, когда зрители пошли ретвитить один твит.
Алсо твитдек раньше позволял ленту любого неприватного аккаунта смотреть, но потом это убрали.

>>15876
Ты конечно сравнил, молодец. Чего не с гуглом сразу?

А Доброчан-онии-тян почему не отжат^H^H^H^H^H попросить? У неё же это всё есть.

>>15850
Ага, знаем мы эти желания.

>>15881
Во-первых, там очень тяжёлый движок, который потребует апгрейда всего что можно. Во-вторых (на самом деле во-первых), с чего бы его Рус кому-то давал?

А что вообще должна делать серверная сторона имиджборда? Сететвую составляющую по разграничению прав доступа тоже можно выгрузить на аутсорс другому ресурсу. Остаются одни операции над базой данных? Не знаю как вам, а мне кажется что выдавать заранее сформированные закешированные шаблону куда быстрее чем каждый раз копаться в базе данных по запросам АПИ. Другое дело, если приходится пересобирать всю доску при каждой отправке очередного поста. Включая давно забамплимиченный тред куда он постится... кхм, извините увлёкся, похоже обсуждение ушло куда то не по теме.

Это всё хорошо, но что с предложенными вариантами скрытия тредов? Запостили сюда два, они были рассмотрены?

>>15891
Ждите, это ж Ычан.

Вобщем, запилил я разворот картинки. Получилось очень неинвазивно, достаточно просто подключить скрипт и вызвать инициализацию в конце страницы, всё. Спойлерон работает, /gf/ отсекается по критерию "ссылка заканчивается на .swf", допустимая ширина картинки берется из эффективной ширины поста. Остается один вопрос - как детектить мобилочки? Страшно, по юзер-агенту, или по-простецки, всё что меньше 800х600 записывать в мобилочки?

>>15893
>Остается один вопрос - как детектить мобилочки? Страшно, по юзер-агенту, или по-простецки, всё что меньше 800х600 записывать в мобилочки?
Может по соотношению сторон окна или по dpi экрана.
>по юзер-агенту
Он же для этой цели создавался.

Предлагаю какому-нибудь ОПу создать на автобусе филиал этих
http://iichan.hk/b/res/3953348.html
http://iichan.hk/b/res/3762663.html
http://iichan.hk/b/arch/res/2452321.html
тредов. А так же (не)оффициальный храм куклоскрипта.

>>15850
>>15857
Сделал вам разворачивалку с учетом мобилочек решил таки по юзер-агенту их определять В архиве примеры с досками /a/ (включая спойлерон) и /gf/. Это самая простая реализация, если она будет принята в целом, я могу подзаморочиться и улучшить визуальную отзывчивость сейчас для пользователя ничего не происходит пока картинка не загрузится, потому что принудительно не изменяется размер элемента img. В примерах из архива большие картинки грузятся прямо с ычана.

Подключается просто. В хедер нужно добавить сам скрипт:

<script type="text/javascript" src="a_files/iithumb.js"></script>

В конце страницы добавить вызов для инициализации:

<script type="text/javascript">iithumbinit()</script>

> в конец страницы добавить
Ну что за колхоз? В сам скрипт вставляешь:

window.addEventListener('load', function () { your init function });

>>15899
Скрипты по-хорошему добавляюься не в head, а как раз перед </body>, так они не замедляют время рендеринга страницы.

>>15900
Но у нас тут не кружок разработки веб-приложений, а вполне конкретное ТЗ. Скрипты будут добавляться в wakaba.js, ибо надо, чтобы работало и в архивных нитях. А там своих функций хватает. Приведенный выше метод позволяет вообще вставлять копипастом, не трогая другие места скрипта.

Короче вот:
https://github.com/WagonOfDoubt/iichan-extensions

>>15899
>>load
Ага, и жди когда загрузятся все картинки. Отказ же.
Там надо было бы по хорошему тогда мультибраузерный ready запилить, но опять таки, допилить что-то если ычановцы попросят не тяжело.

Алсо
>Кроля
>разбирается в JS на уровне "детектить колхоз"
Зачем вообще создавать этот тред тогда, если разработчик у вас уже есть?

>>15903
Ну тогда

DOMContentLoaded

используй.

>>15904
Никто ничего не спрашивает, а я им через libastral что-то должен делать?

>>15899
Ты лучше посмотри как тут на автобусе адаптивная капча и слежение за тредами реализовано. Какие эвенты? Всё прямо во время парсинга DOM-дерева запускается (inline script'ы).

>>15908
Почему его должен волновать местный код?

Мысли насчёт разворачивалок: при наведении на картинку в углу поверх неё показывать кнопку для раз/сворачивания, а клик по самой картинке как обычно в новой вкладке, чем мобилки и будут пользоваться. И выбор тогда в наличии (в идеале конечно меню настроек, как на форчане).

Кнопку не в левом верхнем углу, а например правом, и отключать ссылку на развёрнутой картинке, для чего достаточно превратить её в

javascript:void('изначальный_адрес');

, чтобы легко потом вернуть обратно. Это к тому, что у меня иногда левый клик на мышке 2 или 3 раза при нажатии в одну точку срабатывает, inb4 купи новую. Нынешний интерфейс вполне устраивает, wakaba.js отключен, костыли сам себе пишу.

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

Наверное, самое спартанское решение.
http://codepen.io/anon/pen/vxJLOz

Разворачивалка картинок, перетаскивание не поддерживается
Скрытие тредов, хранение в localstorage

Деплой:
65 строк js
20 css
В отдаваемой верстке нужно добавить элемент .thread-hider. В примере выше это простой span с текстом [X], можно сделать любым - button, image, anything-more-with-background-image...

Поддержка IE: 9+

>>15911
Негодяй-codepen минифицировал js

Вот сырой http://pastebin.com/jQ96wZec

Размер 2.2К

>>15912
А, ну и отключение разворачивалки на мобилках по user-agent.

В целом все это больше на css работает, чем на js - скрытие, максимальный размер картинки, етц. Js только классы переключает и события вешает.
Для широкоформатных мониторов тестировать удобнее так http://codepen.io/anon/pen/vxJLOz/left/

Возможно, также придется по вкусу css-стакование скрытых тредов
http://codepen.io/anon/pen/ryzjGa/left/

Ну вот, получился конкурс какой-то. Лушче б взяли что-то одно за основу и допилили.

>>15922
Сдается мне, никто ничего впиливать в ычан не будет.
В этом треде только 2 типа: одни против каких-либо изменений и вообще скрипты зло нужно сидеть через диал-ап, пользоваться нетскейп навигатором и гуглить в альтависте #вернитемнедевяностовосьмой; и второй - те, кто запилили свои костыли за 5 минут (а больше и не надо) и ждут, что Соус Мод-тян обрадуется и запилит их скрипт на ычан за те же 5 минут.
Ну и есть наверно третий тип, малочисленный, они сидят на ычане и не знают разницы между window.onload и addEventListener, про куклоскрипт не слышали и им и так хорошо, они ждут продолжения "лета".

>>15924
Если бы никто ничего не собирался впиливать, этого треда бы не было.
Чего кого-то теперь нетерплячка бьёт, я не знаю. Это Ычан, дела быстро не делаются, к сожалению. До лета впилят, я думаю, но точнее сроков никто не назовёт.

Э… там рак на горе свистнул? С чего вдруг такие предложения?

Повторю ещё раз - js нужен только для сохранения результатов действий пользователя. В куках или локальном хранилище, не важно. Всё остальное умеют стили. В том числе скрывать и раскрывать по наведению\клику и прочий интерактив. Причём вешать можно уже на имеющиеся классы.

>>15938
>умеют стили. В том числе скрывать и раскрывать по наведению\клику и прочий интерактив
По наведению, понятно, :hover, а вот про то, что стили умеют что-то скрывать по клику, слышу впервые. Нет, в теории, можно впиливать невидимый checkbox перед тредом, а тред обернуть в label, и повесить стиль на :checked+блок_треда, но это настолько костыль, что нет, спасибо.
Так что js должен отвечать за сохранение И за скрытие. За одменистрацией только остался выбор стратегии скрытия, выше есть варианты - js просто добавляет класс, и стиль скрывает тред, или более продвинутые, где происходит модификация содержимого, чтобы, например, выводить текст поста, если тема не заполнена. Если так радеете за аскетичность, первый вариант вполне подходит.

>>15940
>а тред обернуть в label
Спать пора. Кнопку скрытия обернуть в label. Но тут потребуется автогенерация id в чекбоксе и прописывание for в label'e, чтоб они связывались. А это уже не простое впиливание в верстку, а полноценный кодинг на серверной стороне. Оно вам надо?

Мое решение для вас. Убейте вакабу, она давно этого просит.

>>15938
Предлагается картинки раскрывать тоже цссом? Если да, то это будет худшее нововведение Иичана эвар.

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

>Сперва добейся!
Ага, конечно, даже не почешусь. Иначе тогда уж брать и в самом деле готовый проект предлагать.
Кому интересно сами нагуглите. Кому не интересно - можете дальше гореть. Единственное что, повторюсь, результат не запоминается. А значит совсем без js бесполезно.

>>15945
Повторюсь, повторяя еще раз, как я уже говорил, повторяя вышесказанное, повторяю что я повторял, хватит писать глупости, если не имеешь представления.

Вы бы что-ли новости какие-то сообщили.

>>15967

>>15925

Буду признателен если вы пришьете вакабе нормальный tomorrow.

Я тут упоролся и сделал es6-only версию: https://github.com/WagonOfDoubt/iichan-extensions/tree/bells-and-whistles

Я знаю!
М-тян впилит нововведения аккурат к юбилею! Чтобы сырны могли с гордостью вспоминать этот день, говоря, что ждали этого момента 10 лет.

>>15911
Тут это... Добавил свертывание картинки по клику вне ее.
http://codepen.io/anon/pen/qrJbYo/left/

>>15985
> 11 Use '!==' to compare with 'null'. (Google it)
> 12 Don't make functions within a loop. (Google it)
> 18 Don't make functions within a loop. (Google it)
> 47 Use '===' to compare with 'null'. (Google it)
> 70 Missing semicolon. (Google it)
> 3 Don't use IDs in selectors. (Google it)
> 13 Don't use IDs in selectors. (Google it)

>>15986
Спасибо за конструктивную критику, поправил.
С функциями вне цикла получилось на несколько строк больше. Про id в селекторе - сомнительно, т.к. там селектор дочерних элементов. Делать getById а потом на нем выбирать дочерние элементы имхо излишнее усложнение.

>>15974
Слил все в master: https://github.com/WagonOfDoubt/iichan-extensions
Решил оставить es6-версию потому как все актуальные браузеры поддерживают es6, а пользователям Оперы Престо, Эксплорера и телефонов со старым андроидом меньше всего нужны какие либо нововведения. У них скрипт просто не выполнится и все будут довольны. Поддержка оставшихся 5% в приоритет не входит.

Так кто победил в конкурсе? >>16010-кун?

>>16058
Ждем программиста, предсказанного Пророчеством - на белом коне и с большими усами, который сделает
>js нужен только для сохранения
>Всё остальное умеют стили

>>16078

И явится программист на чёрном моноколесе и с большими усами, и имя ему будет Мицгол.

たぶん。

А как насчет того, чтобы на чиочане такую же раскрывалку картинок запилить?

>>16462
Она есть с основания. Только надо на ссылку над файлом нажимать.

А зачем на div с тредом добавлять class="iichan-thread-hidden", если достаточно стилизовать не
.iichan-thread-hidden {display: none}
а
.iichan-hidden-thread-placeholder+div {display: none}
, тем паче что именно через + сделано "раскрытие по наведению". А то получается, скрываем по классу, а раскрываем по другой-класс+див, ну и добавление такого класса выглядит избыточным, не?

Объясните любознательной баке в образовательных целях.

Больно нужно это скрытие. Лучше бы карту постов добавили.

Добрый день!
Интересно было бы увидеть реализацию поддержки .webm для Вакабы (на примере Ычана), imagick в качестве внешней программы. Требования к реализации:
- наличие у видео тамбнейла в виде первого кадра, а не просто заглушка;
- запрет на загрузку файлов со звуком;
- поддержка прочих форматов: .mp4, .ogv;
- плеер по нажатию в теле страницы, а не отдельным окном.

Перспектива расширения функционала ресурса при наличии готового решения достаточно высока.

Достаточно для чего? Реализация из других мест не подходит или вообще не смотрелась?

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

>>17663
Каких «других мест»? Речь идёт о конкретном движке.
Уже есть какая-то реализация на базе Вакабы?

Давайте, я переведу.
ОП хочет, чтобы вы взяли публично доступные исходники «Вакабы» и, поковыряв их, написали для них поддержку видео.
При наличии такой реализации, этот код потом могут позаимствовать на Ычан для введения поддержки видосов там. Да, речь именно про него.
Такая вероятность действительно существует.

Если кто-то где-то уже такое делал, тоже тащите сюда.

>>17665
Есть, но исходники никто не даст.
>>17664
Тут что-то может быть, но я не смотрел.

>>17662
> Вакабы (на примере Ычана)
Исходники модабы ведь закрыты и никому не выдаются.

> наличие у видео тамбнейла в виде первого кадра, а не просто заглушка

convert input.webm[1] thumbnail.png

> imagick в качестве внешней программы

Изрядная нелепость.

В качестве внешней программы для этой задачи гораздо лучше подходит ffmpeg.

>>17669
Эта Ужасно Измененная Модаба, В Которой Нет и Следа Вакабы действительно интригует.

>>17665
Людей, внезапно, на земле много, есть реализация почти всего на основе почти всего. https://github.com/ernstchan/phutaba , например, вполне-таки перепиленная вакаба, только ogv не поддерживает, плеер не встроенный и не отсеивает аудио. Или https://github.com/marlencrabapple/Glaukaba . Или даже https://github.com/lisanyan/wakaba ...хотя, мне кажется, там у них почти одинаковый код, поэтому достаточно было одной ссылки.
Отображение, я вполовину уверен, можно слизать с какого форчонга и всё будет хорошо. У меня до сих пор претензии к развороту картинок на Ычане: при сворачивании обратно вид за ними не утягивается к посту.

>>17666
>ОП хочет, чтобы вы взяли публично доступные исходники «Вакабы»
Дружественное напоминание всем желающим, что последняя версия Вакабы - 3.0.9, хоть и вышла она после создания Ычана. А Ваху надо подвесить за ноги и долго спрашивать, чому у него нет нормального чейнджлога. Вобще никакого чейнджлога.

>>17671
Вообще, я понимаю, отчасти: Вакаба - параноидальный движок, и проверяет даже картинки ручками перед тем как отправить их в комбайн imagemagick. Чем обезопасила Ычан от некоторых уязвимостей. Но не настолько параноидалный, чтобы ручками выковыривать картинку из первого кадра, при, сколько, десятке различных вариантов форматов видео в контейнере? По крайней мере мне ради "существующей вероятности" в совсем байтолюбство лезть неохото, ибо затянется это на месяц, наверное.

> плеер по нажатию в теле страницы, а не отдельным окном

https://github.com/WagonOfDoubt/iichan-extensions/pull/1/files

>>17674

> Но не настолько параноидалный, чтобы ручками выковыривать картинку из первого кадра, при, сколько, десятке различных вариантов форматов видео в контейнере?

Каким образом эту идею («ручками выковыривать картинку из первого кадра») можно было вычитать в реплике >>17671? Я уж не говорю о том, что решение проблемы «выковыривать картинку из первого кадра» в реплике >>17670 только что было дано.

Поясняю мысль: реплика >>17671 была о том, что попытка использовать ImageMagick для того, для чего ffmpeg подходит гораздо больше, рано или поздно наткнётся на труднопреодолимое препятствие.

Или без примера не понятно?

Вот пример: для добычи первого кадра можно попробовать «convert input.webm[1] thumbnail.png» вместо «ffmpeg -frames:v 1 -i input.webm thumbnail.png» (я, впрочем, не пробовал, но по адресу https://stackoverflow.com/a/5430762 это советуют). Однако задача №2 (запрет на загрузку файлов со звуком) ужé может вызвать проблемы, так как ImageMagick вряд ли содержит штучки-дрючки для обращения к звуковой дорожке: это графическая библиотека.

Даже сраные япошки со своим ультраконсерватизмом сделали поддержу шебм.
На задачи нужно смотреть как на возможные алгоритмы, а не как на готовое решение, zdelot-khorosho.js, например. Нет такого понятия, как «реализация поддержки х на у», есть инструмент з, который может делать х и который можно заставить работать в связке с у.

>>17677
>Каким образом эту идею («ручками выковыривать картинку из первого кадра») можно было вычитать в реплике >>17671?
Эта идея из ОП-поста, в котором из сторонних программ указан только ImageMagick, который не может напрямую открывать видео, и использует для этого сторонние программы (http://www.imagemagick.org/Usage/formats/ ). Собственно, по ссылке на stackoverflow говорят ровно об этом же, а именно об ffmpeg. И я считаю, что установка на сервер ещё одного мультемедийного комбайна - достаточно большое отступление от ТЗ ОП-поста.

А дальше в тексте я наоборот соглашаюсь с >>17671.

А ежели всё-таки можно ставить свои комбайны, то я бы добавил сверху Image::ExifTool, и тогда список поддерживаемых форматов ограничивается только самим exiftool.

Ежели это всё дозволительно, то я хоть сегодня (завтра) могу выкатить рабочую версию, с готовым >>17675 тем более что.

>>17682
В принципе, допустимо всё, что есть в репозиториях Debian Strech и CPAN.

>>17682
Please do.

>>17675
Раз все равно будут сайт ковырять, шепните мод-тян чтоб обновила

iichan-expand-images.min.escaped.js

iichan-hide-threads.min.escaped.js

Улучшено юзабилити раскрытия картинок плюс косметические правки кода с учетом пожеланий из прошлых тредов.

>>17662

> запрет на загрузку файлов со звуком;

> плеер по нажатию в теле страницы, а не отдельным окном.

Напрашиваются уточняющие вопросы, и задам:

1) Должен ли видеопроигрыватель автозапускать воспроизведение видеозаписи?

2) Должно ли воспроизведение видеозаписи быть зацикленным (переходить к началу при достижении конца видеоролика)?

3) Точно ли необходим запрет на загрузку файлов со звуком? Может быть, достаточно одного того, чтобы видеопроигрыватель был с приглушённым (до нулевой громкости) звуком?

4) Должен ли видеопроигрыватель иметь пользовательский интерфейс для управления воспроизведением, в том числе перемоткою, паузою и продолжением воспроизведения?

3+4) Точно ли необходим запрет на загрузку файлов со звуком? Может быть, достаточно одного того, чтобы видеопроигрыватель изначально был с приглушённым (до нулевой громкости) звуком, но пользовательский интерфейс его содержал включатель звука?

>>17686
А прoгесс загрузки появился наконец? А то тычешь тычешь и непонятно, разворачивается или нет.

Зачем оно нужно без звука?

>>17688
Да, теперь оно сразу разворачивается в нужный размер.
Можно сразу начать этим пользоваться, если заблокировать адблоком существующий скрипт, добавив правило

iichan.hk/extras/*

, и установить раскрывалку как юзерскрипт отсюда: https://github.com/WagonOfDoubt/iichan-extensions/raw/master/dist/userscript/iichan-expand-images.user.js

>>17687
Думаю, кастомный ГУЙ к видеоплееру не нужен, браузеры и так нормально с этим справляются. Без звука можно смотреть только порноролики, как на Форчане, и то не все. Приглушение тоже не нужно, как никак все умеют пользоваться ползунком громкости.

>>17689

> Зачем оно нужно без звука?

Когда эту идею впервые реализовывал 4chan (о чём примерно 7 апреля 2014 года¹ упоминает по адресу http://blog.4chan.org/post/81896300203/webm-support-on-4chan блогозапись «WebM support on 4chan»), то о WebM помышляли, главным образом, как о замене анимированных GIFов, лишённой недостатков анимированных GIFов, то есть допускающей употребление больше 256 цветов и применение более эффективных алгоритмов сжатия (так что можно надеяться на естественную цветность и на изрядную частоту кадров при сохранении разумного качества и притом при непревышении разумного объёма, каковым в том году сочли объём трёхмегабайтовый). И так как в анимированных GIFах никакого звука не было, то на 4chan и в WebM также решили никакого звука не допускать.

Инерция сознания столь велика, что беззвучными сделались видеозаписи не только на некоторых других таких имиджбордах, которые собезьянничали с Форчана, но также и на таких «не вполне имиджбордах», каков, например, imgur.

Надо сказать, что imgur не только оперативно последовал примеру Форчана в октябре того же (2014) года по адресу https://blog.imgur.com/2014/10/09/introducing-gifv/ во блогозаписи «Introducing GIFV», но и изобрёл для видеозамены анимированных GIFов собственное название (GIFV), а также выбрал для себя противоположный подход к делу: не пользователям позволил загружать видеозаписи в формате WebM на сервер, а на сервере перекодировал загружаемые анимированные GIF в два различных формата (WebM и MP4) и скармливал их пользователю в зависимости от поддержки того или другого во браузере.

Примерно к тому же подходу (видео на основе GIF) склонился по адресу https://telegram.org/blog/gif-revolution 4 января прошлого (2016) года и Telegram.

Недостаток очевиден: и цветность, и вообще визуальное качество таких видеороликов ужасно (потому что в основе их — анимированный GIF).

Почему же тогда такой подход казался разумным?

Дело в том, что тогда (в 2014 году) некоторые операционные системы не поддерживали просмотр WebM (например, macOS, для которой с тех пор появились кодеки, по умолчанию, впрочем, не установленные — или, например, iOS, в которой до сих пор нѣтъ никакой надежды на просмотр WebM ни на айподах, ни на айфонах, ни на айпэдах), а некоторые браузеры не поддерживали просмотр MP4 (например, Firefox, для которого с тех пор в Cisco соорудили кодек http://www.openh264.org/ небывалой лицензионной и патентной чистоты — или, например, браузеры на движке Chromium, который служит основою Google Chrome, но отличается от него открытостью кода и полным отсутствием поддержки патентно-нечистых форматов).

А насколько разумным такой подход кажется сейчас?

Сейчас проблемы в macOS и в Firefox решены, а в iOS и в Chromium остались: до сих пор нельзя посмотреть WebM на iOS или MP4 в Chromium. Вероятно, можно забить на Chromium (в силу малораспространённости) и фигачить MP4.

Со звуком также есть досадная проблема запатентованности форматов, но я не смею долее испытывать терпение читателей /dev/ и предлагаю желающим ознакомиться с четырьмя краткими репликами по адресу https://twitter.com/FidonetRunes/status/929111203355521024 и https://twitter.com/FidonetRunes/status/929111348939804672 и https://twitter.com/FidonetRunes/status/929111538501341186 и https://twitter.com/FidonetRunes/status/929113346279985157 в свободное время, если у кого отыщется оно. Практическое же следствие этой проблемы заключается в том, что Chromium звук AAC не воспроизводит вообще никогда, а Firefox — только в видео MP4 и только при наличии кодеков в операционной системе, как это по адресу https://caniuse.com/#search=aac утверждают.

______________

¹ Точная дата в той блогозаписи не указана (пишут просто «3 года назад»), но о дате нетрудно догадываться, так как «The Washington Post» по адресу http://wapo.st/1qgDoYl в статье «Meet the technology that could make GIFs obsolete» упоминает о новинке как о появившейся в понедельник, а статья эта датируется восьмым апреля 2014 года.

>>17692

> Думаю, кастомный ГУЙ к видеоплееру не нужен, браузеры и так нормально с этим справляются.

Поясняю: я спрашивал не о том, нужен ли кастомный GUI, а о том только, нужен ли браузерный (иными словами, нужен ли атрибут «controls» в теге «video»).

>>17693
> например, iOS, в которой до сих пор нѣтъ никакой надежды на просмотр WebM ни на айподах, ни на айфонах, ни на айпэдах
Это просто пипец. Зачем они живут вообще?

В общем, я тут подумал и по адресу https://github.com/WagonOfDoubt/iichan-extensions/pull/3/files ещё полдесятка атрибутов прибавил к видеопроигрывателю:

1) Автозапуск, чтобы после тычка по предпросмотру не требовалось ещё и с видеопроигрывателем возёхаться для запуска видео.

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

3) Закольцовывание, чтобы после окончания видео просмотр автоматически начинался заново.

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

5) Видеопроигрыватель изначально запускается с приглушённым (до нулевой громкости) звуком, но пользователь может нажать включатель звука.

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

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

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

Ещё сразу скажу, что кроме видеопрогрывателей (на основе тега «video») не помешали бы на имиджбордах и звукопроигрыватели (на основе тега «audio»). А не то даже и стыдно: более десяти лет прошло¹ со дня первых звукопроигрывателей в Интернете, и даже можно файлы MP3 и OGG загружать кое-где (вот здесь², например), но звукопроигрывателей, как назло, нету.

________________

¹ Точная дата появления в Интернете первого звукопроигрывателя мне не известна, однако появление первого видеопроигрывателя относится блогозаписью http://www.wiumlie.no/2007/video/ к 28 февраля 2007 года, а звукопроигрыватели шли в HTML5 рука об руку с видеопроигрывателями, так что и они где-то в это же время были реализованы.

² В качестве примера к моей реплике присоединена звукозапись «Moment of Decision» из альбома «Enigmatic Box of Sound», прилагаемого к визуальному роману «Katawa Shoujo». Автор мелодии — NicolArmarfi. Источник звукозаписи — страница https://www.katawa-shoujo.com/download.php на сайте визуального романа. Право на распространение звукозаписи даётся лицензией Creative Commons BY-NC-ND, на странице https://www.katawa-shoujo.com/about.php указанной.

Контролсы нужно, пусть будут стандартные.

410чан использует флэшёвый звукопроигрыватель из числа тех, происхождение которых восходит к ещё более седой древности Интернета, чем упомянутый выше десяток лет — но увы! флэшёвка в современных Файерфоксах имеет обыкновение обрушиваться (лично у меня этот звукопроигрыватель нормально заработал только с пятого раза).

Кроме того, этому звукопроигрывателю (по сравнению с типичным результатом работы HTML5 audio) сильно недостаёт полосы прокрутки звукозаписи.

>>17680
>Даже сраные япошки со своим ультраконсерватизмом сделали поддержу шебм.
И на форчке тоже есть. Но тоже без звука. А что тут такого, если .gif и так поддерживался?

>>17689
Думаю, для экономии места на сервере и трафика. Часто шебмки делают люди не шибко технически продвинутые и засовывают звук с очень большим битрейтом, недоумевая, отчего их минутный ролик в 360 на 480 пикселей весит больше двадцати мегабайт. Только для этого не нужно детектить звук. Достаточно в два (если не в один) флага ффмпега сделать выпиливание звуковой дороги. Это проще для реализации, сервера и пользователей.

>>17703
На Форчке есть /gif/ и /wsg/. В связи с чем реквестирую расширения /hr/ до полноценной файлопомойки.
Но не об этом. Имелось в виду, что даже они осилили ффмпег и прикрутили его к Футабе.

>>17706
Для экономии места ограничение веса файла до 10 Мб. Юзер сам разберется, что там пережать. А вот загружать музыкальный клип со статичной картинкой, чтобы он оказался без звука довольно глупо.

>>17707
Нехрен борду как плеер использовать, Ютуб и прочее есть.

>>17708
Так и для картинок есть imgur.

>>17709
А для текстов Пастбин.
Моття, сделай!

>>17708
Вот зайдем в любой нормальный webm-тред. Какой контекст имеет например это https://krautchan.net/download/1510837594002.webm/1505676909001.webm видео со звуком и без.

http://yakuji.moe/wakaba/diffs.zip - диффы.
Собственно, wakaba.html в той же папке - работающая Вакаба 3.0.9 на свежайшем Debian Sid.
Весь жс взят от Мицгола/вагона сомнений. Для работы требует установленных ffmpeg и libimage-exiftool-perl помимо всего прочего, что требуется для работы Вакабы.

Собственно, как я озвучил на месте, проблем с нынешней реализацией три:
1. Нет сворачивания плеера обратно в картинку.
2. У меня едут миниатюры, но это проблемы моего юзерстиля, так что это не проблема.
3. Я не тестировал это на чём-то кроме webm, отчего могут быть сюрпризы.
4. Я хочу спать.

>>17714
> Нет сворачивания плеера обратно в картинку.
Это должно быть. И Дебиан нужен стабильный, если мы об Ычане говорим.

>>17716
>И Дебиан нужен стабильный, если мы об Ычане говорим.
Я не буду даунгрейдить свой сервер, но что ffmpeg, что libimage-exiftool-perl в Stretch есть, я гарантирую это. Даже в Wheezy. В последнем только самого webm может не быть.

>>17717
Вопрос в том, работают ли эти версии аналогично более новым из тестинга.
Ну, и виртуалку никто не отменял.

>>17718
>Вопрос в том, работают ли эти версии аналогично более новым из тестинга.
Перловская либа выпадает из вопроса, так как она в крайнем случае берётся из CPAN, что разрешено >>17683. Стречевскому ffmpeg меньше года и на оффсайтеничего про глобальные изменения с того периода нет.
>Ну, и виртуалку никто не отменял.
Ну и флаг вам в руки, если мне веры нет. А я вернусь часов через 16-20.

>>17714

> Нет сворачивания плеера обратно в картинку.

>>17716

> Это должно быть.

Ну хорошо.

https://github.com/WagonOfDoubt/iichan-extensions/pull/4/files

>>17671
>>17674
Передача видеофайла в ffmpeg, ImageMagick или любой другой "комбайн" с поддержкой десятков форматов файлов и кодеков практически равнозначна разрешению кому угодно выполнять произвольный код с теми же правами, с которыми будет запускаться этот "комбайн". Поэтому важно откомпилировать ffmpeg с поддержкой только WebM, MP4 и OGV и обеспечить его запуск с минимальными правами в "песочнице" SELinux/Apparmor или в виртуальной машине либо на отдельном сервере.

>>17734

Перекомпилировать-то нафига?

Насколько я помню, в прошлом году уязвимость https://imagetragick.com/ отключалась просто-напросто таким изменением конфигурации в файле «policy.xml», которое отключало уязвимые «кодеры».

>>17725
>insertAfter
Нет такого в дефолтном ЖС.

Поправил кое-как у себя локально. Заодно проверил другие форматы и тестово разрешил звук.

Писать версию с удалением звуковой дорожки ннадо кому, или мы уже закончили с этими вероятностными играми?

>>17739

Благодарю за замечание, по адресу https://github.com/WagonOfDoubt/iichan-extensions/pull/6/files скинул поправку.

>>17741
Ах да, забыл добавить: dataset хранит информацию в DOMString. Поэтому условие в строке 16 всегда истинно после первого открытия видео, а строка 19 не работает вообще. JSON.stringify с последующим JSON.parse не решает вторую проблему, ибо removeChild оперирует на DOMNode, а JSON возвращает Node.
Первое я решил проверкой на undefined с последующим

delete e.currentTarget.dataset.videoMode;

, второе через позиционирование:

parentNode.removeChild(e.currentTarget.previousSibling);

. Но может у вас есть идеи получше. Скажем, генерировать id видеоплееру через a.name, и удалять по getElementByID.

Да, я есть на гитхабе, но бегаю от sparky4, и слишком мало знаю ЖС, чтобы разбираться в правильности и красивости своих решений.

>>17743

Подумавши над таким поведением «dataset», я решил внести изменения https://github.com/WagonOfDoubt/iichan-extensions/pull/7/files в свой код, то есть не только перейти к хранению текстовых строк, но и хранить их в «левых» атрибутах объектов DOM, а не в «dataset», так как MDN по адресу https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset сообщает о том, что «dataset» не поддерживается в Internet Explorer ранее версии IE11 (тогда как тег «video» согласно https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video поддерживается от версии IE9).

Приходится признать, что на меня дурно повлиял пример WagonOfDoubt с появлением использования «dataset» в изменениях, внесённых коммитом https://github.com/WagonOfDoubt/iichan-extensions/commit/b067eb068f560275bac848100e7c39b600b24ab6 в исходный код развёртывания иллюстраций на Ычане. Я некритически решил, что если там так делается, то и ладно; а отнюдь не ладно то было.

>>17714

Смотрел http://yakuji.moe/wakaba/diffs.zip

Много думал.

Вид файла wakaba3.diff начиная от строки 31 создаёт уверенность в том, что там используется код, соответствующий стандарту ECMAScript 2015 и оттого нифигушеньки не поддерживаемый в более ранних браузерах.

Возможно, есть смысл наперёд собрать его тем способом, который WagonOfDoubt упомянул по адресу https://github.com/WagonOfDoubt/iichan-extensions#Сборка-для-продвинутых-бак (или, иными словами, в последнем из разделов в readme.md).

Этот способ потребует (в качестве сборочных инструментов) Node.js и Gulp и ещё четырнадцать штук тех модулей, которые командою npm install будут установлены (они по адресу https://github.com/WagonOfDoubt/iichan-extensions/blob/d854d58843a3d5c3b69a20e06bb1f5188779451d/package.json#L24-L39 перечислены), но в итоге должен получиться (в подкаталоге «dist») исходный код, пропущенный через Babel для перевода на более раннюю версию JavaScript.

>>17762
Благодарю за инструкцию. Собрал, оставил только нужный функционал, переархивировал. Взял iichan-video-player.min.escaped.js , ибо на самом Ычане, похоже, также использован min.js, а не es5. Но всегда можно поправить ещё раз.

diff'ы такие большие, ибо я подозреваю, что состояние Вакабы Ычана достаточно отличается от ванильной, чтобы разумнее было ориентироваться по именам функций и всем близлежащим строкам, чем по номеру строки или только имени функции.

Нужна реализация, аналогичная тому, как это сделано на Форчане, где файлы со звуком просто не допускаются. Никаких игр с ползунком громкости\редактированием файла не нужно.

>>17769
На Ычане не использован es5.js так как хоть babel может заставить заработать js-код на более старых браузерах, с css-свойствами он такого сделать не может, а на css завязан основной функционал этих скриптов. Таким образом, более вероятна ситуация, когда код работает как надо, а css не работает вообще, либо работает неправильно, в результате имеем поломавшийся функционал. С esNext же получается graceful degradation, когда код, обернутый в try...catch тихо падает, а пользователь видит ванильную Вакабу образца 2007 года и ничего не замечает. Впрочем, как знаете. Все версии есть в наличии.
Еще по поводу video-player.js:

margin: 2px 20px;

Точно ли тут должен быть margin, а не padding?

>>17771
Звук нужен. .webm не только замена анимированному .gif, который и так можно постить, но и замена уже не поддерживающемся нигде флешу, который в свою очередь в свое время и воспринимался как "гифки со звуком".

>>17774
Я ещё раз повторяю, в рамках описанной в ОП-посте реализации звук в .webm не нужен. Варианты со звуком на Ычан ставить никто не будет.

>>17777>>17774
Специально для вас написана версия, где допускание звука настраивается константой в конфиге, и в диффе версия "не допускать звук".
>Варианты со звуком на Ычан ставить никто не будет.
[citation needed]. Я-то в треде вижу кучу анонимов и одного Соус-куна, что хоть какую-то гарантию может дать (да, есть ещё Мицгол, но это иррелевантно к теме обсуждения). И он про звук ничего не сказал. Как и про другие требования ОП-поста.
А то про вебм вообще я помню, что не будет, но про конкретно звук нет.

>>17773
>Точно ли тут должен быть margin, а не padding?
Я не знаю, ололо, я просто скопипастил Мицголовский код. На глаз разницы не вижу.
>Все версии есть в наличии.
И ВагонСомнений на момент написания принял патч, так что они есть даже на гитхабе. Вот и славно.

Пока что я увѣренъ, что margin.

(Если у кого-нибудь есть аргументы в пользу padding, то я готов их послушать.)

Аргумент >>17773 о неправильной работе CSS представляется мне по отношению к моему исходному коду видеопроигрывателя преувеличенным и неверным. Рассмотрим использованные мною правила CSS по одному:

правило «max-width: 100%» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/max-width#Browser_Compatibility работает, начиная от Chrome 1, Firefox 1, Opera 4, IE7, Safari 2.0.2, во всѣхъ Edge,

правило «height: auto» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/height#Browser_compatibility работает, начиная от Chrome 1, Firefox 1, Opera 7, IE4, Safari 1, во всѣхъ Edge,

правило «margin: 2px 20px» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/margin#Browser_compatibility работает, начиная от Chrome 1, Firefox 1, Opera 3.5, IE3, Safari 1, во всѣхъ Edge,

правило «box-sizing: border-box» согласно https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing#Browser_compatibility работает, начиная от Chrome 10, Firefox 29, Opera 7, IE8, Safari 5.1, во всѣхъ Edge —

и, следовательно, именно это последнее правило более требовательно ко браузерам, чем любое из предшествующих. Мы видим, однако же, что даже оно во всех современных браузерах будет работать невозбранно: всѣ перечисленные браузеры — настолько старые версии, что у большинства пользователей стоят либо они, либо, что ещё вероятнее, ещё более новые версии.

Страница https://caniuse.com/#search=box-sizing называет это большинство равным 97½% в мире и 83½% в России.

К тому же, если уж у кого-то до сих пор IE7, например, то у него (в силу дырявости браузера) много больше проблем, чем отсутствие видео на Ычане, так что вряд ли есть смысл от этого человека дополнительно ограждаться — в особенности если речь идёт об ограждении употреблением ECMAScript 2015.

Ведь это же недавняя штука — ECMAScript 2015.

Возьмём, например, такую функцию ECMAScript 2015, какою являются стрелочные функции. По адресу https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility нетрудно видеть, что она вообще не поддерживается в Internet Explorer, а также требует Chrome 45, Firefox 22, Opera 32 и Safari 10 или Edge.

Сравним это с поддержкою тега «video» — и мы увидим, что по адресу https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#Browser_compatibility имеющею её названы браузеры Chrome 3, Firefox 3.5, Opera 10.5, IE9, Safari 3.1 и всѣ Edge.

Я понимаю, что Internet Explorer можно не любить; я и сам не очень-то к нему расположен.

Но так-то уж зачем.

>>17782
Я думаю, >>17773-кун говорит больше об уже поставленных на Ычане скрытии треда и раскрытии картинок.

http://yakuji.moe/wakaba/diffs_es5.zip - версия с es5. На сервере на данный момент тоже она.

Хочу подчеркнуть, и̲ ̲п̲о̲д̲ч̲ё̲р̲к̲и̲в̲а̲ю̲, что WagonOfDoubt своим коммитом https://github.com/WagonOfDoubt/iichan-extensions/commit/de5b64605a5fbe8ace94f51384ce887d04dc4e7d напилил генерирование минифицированных версий на языке ES5, вот как https://github.com/WagonOfDoubt/iichan-extensions/blob/5ad9cee75f557037bdf947f7f87de43a4f1eebb1/dist/es5/minified/iichan-video-player.es5.min.js например.

Именно их рекомендую употреблять на Ычане.

>>17787
¯\_(ツ)_/¯

Обновил архив, взял iichan-video-player.es5.min.escaped.js просто потому что могу.

>>17782
Самое криминальное правило там это pointer-events в hide-threads.js, которое поддерживается в IE11 и выше. https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
В принципе, ничего особенного в этом нет. Не поддерживаемое правило приведет к тому, что треды будут раскрываться по наведению на всю заглушку, а не только на ссылку с номером. Так что действительно, пусть будет es5.

>>17778
Что вам от меня надо? Я, вроде, ясно написал, что ОП легитимен, хоть и криво изъясняется.
Да, по умолчанию требуется без звука. Если в конфиге есть опция для звука, то пусть будет, я не знаю.

Алсо, просили передать, что неизвестно, когда это будут прикручивать. Но сама возможность прикручивания одобрена.

Очень хорошо.

>Я, вроде, ясно написал, что ОП легитимен
"Давайте, я переведу. ОП хочет" и "Такая вероятность действительно существует" не легитимность, а жест доброй воли и совпадение в моём словаре. Или криво изъясняется не только он, или криво устроен я, что тоже бывает.

>Алсо, просили передать, что неизвестно, когда это будут прикручивать. Но сама возможность прикручивания одобрена.
Вот и славно. Ждать, как всегда, осталось недолго.

Я даже не буду говорить, кто тут продажный женщин.

>>17796
>2015
>в ближайшей перспективе

>>17797

Вот точно. 2¼ года прошло, какая уж тут «ближайшая перспектива».

>>17797
>пять лет прикручивали прозрачность превьюхам

>>17800
Её когда решили прикрутить, прикрутили очень быстро.
Это вот видео решили прикрутить только сейчас, и прикрутят неизвестно когда.

>>17801
Тут должна быть цитата из нубтайпового интервью Мт про дальнейшее развитие Иичана, за которую там пару лет назад банили почему-то.

>>17802
В интервью хотелки были абстрактные (вспомнить хоть торренты и музыку, которую из-за копирайтоты никто бы в здравом уме прикручивать и не стал). И в то время вообще мало что осмысленное делалось по любым направлениям.
А когда прозрачность всё-таки действительно решили приделать, её приделали быстро. Каталог, вроде, тоже.

>>17802

Правильно ли я понимаю, что рѣчь идётъ объ интервью въ номерѣ http://ichan.ru/NT11.pdf и о слѣдующихъ въ нёмъ словахъ:

> Вот те из видимых посетителям изменений, которые мне хотелось бы добавить в первую очередь: поддержка .torrent файлов в /t/, .pdf в /sci/, возможно, сейвов в /to/, музыкальных форматов в /mu/, .flv и роликов с Youtube в /gf/ (?), канакапча, EXIF’ы в /ph/, LaTeX в /sci/, анимация в /o/, исправление ошибок в CSS и в обработке «^ H» в Wakabamark’е, список досок во фрейме, который можно сворачивать, новая титульная страница.

>>17803
Ну, там были и вполне ясные и чёткие цели.
В любом случае, понятия о времени и временных рамках с Иичаном слабо коррелируют.

>>17805
Да.

По причинам, в обсуждении >>/d/958 изложенным, предвижу много более частое употребление MP4, нежели WebM.

>>17782
> (Если у кого-нибудь есть аргументы в пользу padding, то я готов их послушать.)

>>17796
Как будто Мод-тян - не переходящая должность, и нынешняя несёт ответственность за слова прошлой.

>>17820
Они как раки-отшельники.

>>17820

Если не совершают широкого объявления «Моконы и Сырны! С вчерашнего дня я правлю над вами — другая Мод-тня!», то тогда, значитца, последующая Мод-тяночка желает возыметь репутацию предыдущей и как бы играть впредь роль её.

Но ведь и воспоминания о прежних декларациях намерений — часть той репутации. Иначе и быть не может.

>>17817

По адресу https://github.com/WagonOfDoubt/iichan-extensions/commit/37e5e52040d80b18fc012c800c18693cd4e57c5c видно, что WagonOfDoubt напилил padding куда надо, а также придал поля гиперссылке, свёртывающей видеопроигрыватель.

Что же касается меня, то после пристального вглядывания в >>17817 я принимаю мнение о том, что именно padding там надо.

До этого у меня были определённые иллюзии (которые я уж не стану тут пересказывать) о том, как работают поля (и вообще box model) у видеопроигрывателей.

>>17826
Там, кстате, надо ещё width:auto, чтоб не було ак в >>17744.

>>17829
По адресу https://github.com/WagonOfDoubt/iichan-extensions/raw/master/dist/userscript/iichan-video-player.user.js можно установить юзерскрипт, и тестировать его на nowere.net, так как там тоже wakaba и есть поддержка .webm

>>17829

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

Именно в силу такой убеждённости я могу небезосновательно надеяться на то, что уж моего-то видеопроигрывателя это обстоятельство нисколько не коснётся — прежде всего потому, что вызов в строке https://github.com/WagonOfDoubt/iichan-extensions/blob/aaa2c661e548323e7b0e56bac4105d1dbcff91f3/src/video-player/video-player.main.js#L36 располагает видеопроигрыватель вне того элемента, который помечен классом «.thumb» (и даже вне окаймляющей этот элемент гиперссылки).

Разумеется, если у кого-нибудь есть контраргументы, способные всерьёз поколебать эту убеждённость и порождённую ею надежду, то прошу высказываться; но до тѣхъ поръ — — —

Слѣдованіе совѣту >>17830 позволило мнѣ увидѣть, что, напримѣръ, видеороликъ http://nowere.net/cg/res/2920.html не искажается по ширинѣ, такъ что вродѣ какъ нечего и пытаться тутъ починить то, что не сломано.

>>17830
>>17832
О, а я могу-таки себя оправдать.
Иичановская открывалка кортинок использует бгомерзкий calc для максимальной ширины с константой под маргины, от которого можно избавиться, заменив один костыль (в виде нынешнего calc) на другой (в виде box-sizing и всего прочего).

>>17835

>>17835

Ну дык WagonOfDoubt это самое по адресу https://github.com/WagonOfDoubt/iichan-extensions/commit/b067eb068f560275bac848100e7c39b600b24ab6#diff-0d5f41f25ce9bcf42091fc838b3d054fR52 и сделал шестнадцатого числа.

Осталось накатить на Ычан.

>>17836
>>17837
Ну не стукойти!
width:auto там всё равно нету.

>>17838

По-видимому, этого не нужно потому, что WagonOfDoubt той же правкою обеспечил задание ширины иллюстрации через JavaScript.

При рассмотрении кода https://github.com/WagonOfDoubt/iichan-extensions трудно удерживаться (и не удерживаюсь, не удерживаюсь!) от убеждённости в том, что его сложность непомерна по сравнению с той, которой этот исходный код обладал бы в том случае, если бы Ычан использовал jQuery (джаваскриптовую библиотеку, по адресу http://jquery.com/ предлагаемую).

Это касается и каких-то мелочей, вроде ошибки >>17741 с последующею необходимостью использовать длиннокод «parentNode.insertBefore(vp, e.currentTarget.nextSibling)» вместо jQueryйного «$(this).after(vp)» из трёх слов.

Это касается и более крупных архитектурных вещей: например, целый десяток строк кода функции «init» по адресу https://github.com/WagonOfDoubt/iichan-extensions/blob/1564715cb31f7e30ba617b39b7d9192e6334aa23/src/expand-images/expand-images.main.js#L57-L66 и весь внешний цикл в вызываемой функции «addListeners» сочинён для того только, чтобы, во-первых, навесить обработчик жмяка мышою на каждую миниатюру, а во-вторых, при необходимости повторить это навешивание, когда число миниатюр в коде документа увеличивается (при подкачке и развёртывании обсуждений?…) — тогда как в случае jQuery достаточно было бы единственного обработчика, в коде «$('body').on('click', '.thumb', …)» на месте многоточия указанного, и в силу jQueryйного механизма всплытия и делегирования событий эти четыре нехитрых слова заменили бы более дюжины строк нынешнего кода-обёртки.

Более всего неприятны последствия того, что эта обёртка использует конструктор «MutationObserver», который по словам https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver#Browser_compatibility появился только в достаточно новых браузерах (Chrome 26, Firefox 14, Opera 15, IE11, Safari 7, всѣ Edge) — особенно пагубно его отсутствие в Internet Explorer ранее одиннадцатой версии: с остальным-то ещё можно было бы примириться, а тут явное ограничение тех браузеров, в которых ещё могло бы работать развёртывание и миниатюр, и даже видеозаписей.

Такое положение дел нельзя терпеть.

В довершение отмечу, что совершенно того же всплытия и делегирования событий сильно недостаёт, например, тому исходному коду показа родительских реплик в обсуждениях на 410чанѣ, который без jQuery поневоле был сочинён таким менее функциональным способом, от которого при наведении на «>>циферки» хотя и всплывает желаемый прямоугольник с указанною репликою, но зато не всегда: если «>>циферки» появились в документе попозже начальной его загрузки (через нажатие на кнопку «Expand Thread»), то тогда не всплывает.

>>17862

> Такое положение дел нельзя терпеть.

Напилил https://github.com/WagonOfDoubt/iichan-extensions/pull/10/files для подкачки и употребления jQuery.

Дополнительно сообщаю, что на Ычане надо отпилить атрибут «type="text/javascript"» ото всех HTML-тегов «script», потому что и без него по умолчанию так.

>>17863
Давайте может не будем пихать людям в глотку сторонние либы, когда решение уже есть?

Плюс, это прямо противоречит >>15850:
>Желательно, чтобы скрипты были достаточно легковесны, чтобы помещаться в wakaba.js. Минимальными должны быть и предлагаемые правки вёрстки самих страниц (радикально никто ничего перепиливать не будет).
>Предпочтительная лицензия скриптов — общественное достояние (public domain), как у самой «Вакабы».
>Пока всё. Администрация не рассматривает идеи подключения куклоскриптов или чего-то подобного тяжеловесного целиком, так как стремится сохранить минимализм интерфейса сайта.

>>17866

Когда они пришли за работоспособностью дополнений Ычана в подкачиваемой части обсуждения в IE9 и в IE10, я молчал.

Я не был пользователем IE9 или IE10.

>>17881
Они и без MutationObserver в IE10 вполне работоспособны.

>>17882

Работоспособны только после того,¹ как WagonOfDoubt внёс в код правку https://github.com/WagonOfDoubt/iichan-extensions/commit/132f8bba2fb2f1af87b21161327ef73053b73d9c для проверки на существование конструктора MutationObserver.

А без этого код функции «init()» выпадал бы в IE9 и в IE10 с ошибкою, я так думаю. Да и как бы не выпасть ему?

____________

¹ Скрипт сырнифицирования потребовал также внесения более поздней правки https://github.com/WagonOfDoubt/iichan-extensions/commit/d37f03a10b0ff638e2735330a3a67666964c6a96 для обеспéчения таковой работоспособности.

>>17825
Мне кажется, там договорённость такая. Никто не должен говорить о смене Мод-тян. И вообще это всё миф. Хотя Мод-тян образца 2008 сильно отличается от нынешней.

>>17911
Человек мог измениться за десять лет.

>>17912

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

>>17950
Мицгол, зачем тебе эти видео? Картинок не хватает?

>>17971
Картинок, очевидно, не хватает. Никогда не хватало, иначе бы не использовали дикий костыль в виде .gif. Сейчас особенно не хватает, иначе не было бы буквально на 95% ресурсов поддержки хотя бы .webm. Даже на традиционно отстающих в техническом плане на десять лет японских бордах давно поддержка есть, это вообще нонсенс.

>>17971
«Шоб было», очевидно же.

>>17971

Обсуждать аниме и не иметь возможности видеоцитирования — вот что заслуживает объяснения, а не «зачем?»: появление первого HTML5-видеопроигрывателя относится (как по блогозаписи http://www.wiumlie.no/2007/video/ видно) к 28 февраля 2007 года, и если с тех пор на протяжении десятилетия (десятилетия, カルル！） никто не почесался с реализацией на имиджборде, то это ё█░▓ый стыд.

(Ещё я в /dev/ упомянул одну такую российскую имиджборду, на которой видео поддерживается со звуком, но мою реплику стёрли, вероятно сочтя её нарушением запрета на разжигание межчановской розни. Так что здесь не будет аргумента «берите пример с…», а придётся обойтись аргументом «давно пора и очевидно для чего».)

>>18002
Я думал, ты сам стёр
Да, даже на Футабе есть, причём давно.
> одну такую российскую имиджборду
У нас одна крупная имиджборда, и на ней мало что поддерживается вообще.
Кстати, Соус мог бы у себя сделать уже и показать пример.

>>18014
>Кстати, Соус мог бы у себя сделать уже и показать пример.
А на кой хѣръ оно мне надо?
И с нашими нынешними темпами это всё равно будет позже Ычана, даже если мне напишут код.

Автор реплики >>18375 огласил идею показа бамплимитнувшихся обсуждений внутри каталога.

>>18406
Это не то, что могут сделать третьи лица.

>>18412

Если только третьи лица не вздумают посредством AJAXового обходчика самостоятельно собрать с доски список активных обсуждений, затем сверить его с содержимым страницы каталога и поместить в её конец под заголовком «Бамплимитнувшиеся:» те обсуждения, которые в каталоге отсутствуют.

>>18014

> У нас одна крупная имиджборда, и на ней мало что поддерживается вообще.

А что я тогда за гиперссылку по адресу https://krylov.cc/prnt.php?id=18497 вижу на MP4 со звуком? Или это очередной заговор умолчания в духе there's no Tsukihime anime? Ну умалчивайте, чё.

>>18413
Вообще, я мог бы открыть свои подосковые каталоги, со счётчком постов и сортировкой тредов примерно совпадающими с настоящими. Только там список напополам с 404 и архивными за день, что мне без отмашки открывать совершенно не интересно.

>>18415
Ну мы подразумеваем имиджборды, а не чаты для гыгыкающих школьников.

>>18425

Возможно.

Надеюсь только на то одно, что аргумент «даже чаты для гыгыкающих школьников возымели поддержку WebM и MP4, а ты — нѣтъ», во-первых, от этого не становится менѣе вѣсомымъ, а во-вторых, никому и в голову не придёт пойти на него в атаку с контраргументом «дык именно поддержка WebM и MP4 превращает имиджборды в чаты для гыгыкающих — и даже, страшно выговорить, для гыгыгыкающих! — школьников» наперевес, потому что это не так, а всё дѣло въ культурѣ модераціи.

>>18431
Я не против .webm и .mp4, ведь даже японская Футаба ввела поддержку. Просто не надо смотреть на какие-то "сайты для гыгыгыкающих школьников" в качестве примера.

Приделали эти ваши видосы.

Алсо, просили передать, чтобы вы синхронизировали код скриптов с используемой на Ычане версией, если вдруг будете предлагать правки.

>>18461
>эти ваши
Не наши, а ваши. Я вообще бы в /gf/ сидел.
>чтобы вы синхронизировали код скриптов с используемой на Ычане версией, если вдруг будете предлагать правки.
Яваскриптов? А то я, например, по ним никакие правки предлагать не буду, а яваскриптерам моя тестовая доска для отладки вообще не сдалась.

>>18462
>Яваскриптов
Да, это про них.

Что-то с размерами thumbnail'ов, при заходе в нить по ссылке где-нибудь в конце позиция скачет по мере подгрузки превьшек. При отключении js такого нет.

>>18507
Ничего не поняла.
Превьюшки не сразу появляются?

>>18508 Поведение такое, будто у thumnail не указан размер. По мере их подгрузки вертикальный размер страницы меняется, соответственно, если это был переход по ссылке извне куда то в конец треда, по #anchor например, то позиция "улывает" по мере подгрузки превьюшек.

>>18509 И такая фигня под ФФ, хромиум не страдает.

Мне кажется, эта превьюшка шире чем надо.

>>18511
Под каким именно? Гекко или Блинк?

>>18512
Вот это совсем странно.

>>18513 гекко

>>18512
В мобильную версию вмешивается max-width из скрипта, очевидно.

По поводу кортинок. Совас, Автобусу тоже можно прикрутить.

Просто Соломоново решение. Как грится, сделать так, как у конкурента, если у него лучше, значит не спиздить, а позаимствовать опыт.

.filesize~a[src*="/src/"]{

    float:left;

    margin:2px 20px;

}

.thumb{

    max-width:100%;

    height:auto;

}

Желательно повесить на ссылку кортинки отдельный класс, дабы таких костылей не городить, как в первой строчке.
Суть: отступы регулируются контейнером самой кортинки (ссылкой), из-за чего кортинка при max-width:100% будет растягиваться с учётом отступов всех родительских контейнеров. Не нужны ни какие калки, ни бокс-сайзинги — никаких цсс3-костылей. А главное, будет корректно работать даже у некрофилов.

>>18517
Ах, да, остальные стили, касающиеся .thumb следует заранее убрать, есессно.

>>18516
Моё дело - доложить. И бузить за отсутствие исправлений.

>>18517
При чём тут .filesize вообще?

>>18520
При том, что это крайний элемент с уникальным классом в блоке с ссылкой кортинки.
Почитай про ~. Оно берёт файлсайз и ищет последующие ссылки с атрибутом src, в котором есть /src/.
https://developer.mozilla.org/ru/docs/Web/CSS/General_sibling_selectors

>>18517
Не знаю, у меня браузер эту фитюльку с тильдой не воспринял. Ни через сование через инструменты разработки, ни просто прописанную в файле.

>>18522
Едрить-колотить, смотрю на одно, пишу другое.
.filesize~a[href*="/src/"] же. Срц в кортинке.

>>18519
Исправлено путем добавления в css скрипта media query. Теперь оно в принципе с мобильными конфликтовать не может. Осталось бузить чтоб на Ычане обновили expand-images на свежую версию с репозитория.
Еще в https://iichan.hk/css/.global.css зачем-то мусор поместили:

.${EXPANDED_THUMB_CLASSNAME} {

    max-width: calc(100% - 42px);

}

Оно там ненужно раз, ничего не делает два, вообще не валидный css три.

>>18536
Товаристч, проверьти >>18517 и >>18523. Возможно, наш конфликт калк против бокс-сайзинг будет решён.

Кстати, можно доработать скрипт ресайза картинок и реализовать ленивую загрузку. Всем картинкам в треде атрибут src переименовать например в img-src, а картинкам попадающим в видимую область менять обратно.

>>18509
Исправьте, пожалуйста. Очень неудобно стало.
Тоже FF, 57.

>>18540
>>18509
Похоже что был виноват height: auto;. Исправлено, см. последний коммит в репозитории.

>>18539
От этого оверчан может сломаться.

>>18543
А если завтра кардинально изменится вёрстка страницы?
Изменение достаточно сделать посредством жс. Оверчану от этого, ни холодно, ни жарко.

>>18539

> попадающим в видимую область

Рекомендую (во избежание тормозов) не руками проверять попадание в видимую область, а использовать интерфейс https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API для этого.

Сообщаю это по собственному опыту: по адресу https://github.com/Mithgol/phido/commit/b81bba41313cea46954cd38b06ee72d93c190733 попробовал и испытал заметное ускорение.

>>17662

> - запрет на загрузку файлов со звуком;

Этот запрет контрпродуктивен.

По адресу https://iichan.hk/a/res/1364782.html ычаньки обсуждают эндинги, и им даже нельзя позагружать их для прослушивания.

>>18545

> Изменение достаточно сделать посредством жс. Оверчану от этого ни холодно, ни жарко.

Это как?

Если с сервера картинки будут поступать с атрибутом «src», то Оверчану не будет ни холодно, ни жарко, однако и ленивой загрузки не получится: браузер накинется картинки эти грузить, даже если джаваскрипт накинется менять у них «src» на «img-src» несколько позже.

Если же прямо с сервера картинки будут поступать с атрибутом «img-src», то можно ли утверждать тогда, что Оверчану не будет ни холодно, ни жарко? — никоим образом нельзя!

>>18433
> .mp4, ведь даже японская Футаба ввела поддержку
Предоставь пруф, что именно .mp4 поддерживается на футабе тоже.

Когда исправление >>18507 применят? Фикс 4 дня на гитхабе лежит.
https://github.com/WagonOfDoubt/iichan-extensions/blob/master/dist/escaped/iichan-expand-images.min.escaped.js

При очередном обновлении скрипта слетело правильное масштабирование картинок с учётом ширины экрана.

>>18647
Ой. Пофикшено. Ссылка та же.

>>18618

Футаба поддерживает только WebM.

Сообщаю тот формат вызова FFmpeg из командной строки, которым сам пользуюсь в пакетных файлах для создания MP4 и WebM без звука и без субтитров:

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libx264 -crf %2 -preset veryslow -tune animation -profile:v baseline -level 3.0 -movflags +faststart ibvideo.%2.mp4

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libvpx-vp9 -crf %2 -b:v 0 -tile-columns 2 -threads 8 ibvideo.%2.webm

Подстановка параметров записана тут в стиле Windows («%» + номер), под неWindows переделывается тривиально.

Предполагается вызов, например, команды «имяПакетногоФайла имяВидеоФайла.mkv 22 3:33 5:55», где «22» — значение CRF (Constant Rate Factor), а «3:33» и «5:55» — отметки времени (откуда и докуда вырезать фрагмент из видеофайла «имяВидеоФайла.mkv»).

Предполагается простая возможность раз за разом вызывать одну и ту же команду с прежними значениями отметок времени, но с разным CRF, значение которого удобно записывается в имени выходного файла, что в дальнейшем позволяет подбирать его шаг за шагом — то есть можно, например, сравнить по размеру файл «ibvideo.40.webm» (с CRF 40) и «ibvideo.38.webm» (с CRF 38) и прийти к выводу, что первый меньше трёхмегабайтового предела, а второй больше его, так что можно запустить команду ещё раз со значением CRF, равным 39, и тогда точно будет видно, какой файл грузить на Ычан.

Дополнительное чтиво:

https://trac.ffmpeg.org/wiki/Encode/H.264 ← пособие по параметрам кодирования H.264 в MP4

https://trac.ffmpeg.org/wiki/Encode/VP9 ← пособие по параметрам кодирования VP9 в WebM

https://developers.google.com/media/vp9/settings/vod/ ← гуглопособие на ту же тему

https://ffmpeg.org/ffmpeg.html ← перечень общих параметров командной строки FFmpeg

За неимением звука у некоторых ычанек возникает желание фигачить субтитры растром в видеозаписи, и фигачат.

В полном объёме этот трюк рассмотрен по адресу https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo в вики FFmpeg, а вкратце достаточно прибавить параметр «-vf subtitles=%1» к любой из двух вышеприведённых командных строк и тем невозбранно достигнуть желаемого.

Файл «%1» («имяВидеоФайла.mkv» или как его там) при этом должен содержать субтитры (а в большинстве видеозаписей аниме так и есть), а имя этого файла должно быть простым (FFmpeg склонен воспринимать как служебный символ, например, апостроф, хотя в названиях некоторых файлов аниме он есть — придётся переименовывать их перед употреблением).

>>18015

> И с нашими нынешними темпами это всё равно будет позже Ычана, даже если мне напишут код.

Так и вышло.

>>18692
Кода-то никто не написал.

>>18694

Ну дык¹ никто и не сказал вместо «на кой хѣръ надо» слова «интересно было бы увидеть», «перспектива внедрения высока», «требования к реализации — такие-то».

__________

¹ К моей реплике присоединена звукозапись «Friendship» из альбома «Enigmatic Box of Sound», прилагаемого к визуальному роману «Katawa Shoujo». Автор мелодии — NicolArmarfi. Источник звукозаписи — страница https://www.katawa-shoujo.com/download.php на сайте визуального романа. Право на распространение звукозаписи даётся лицензией Creative Commons BY-NC-ND, на странице https://www.katawa-shoujo.com/about.php указанной.

Кстати, напиливать там всего ничего: в функцию «createThumbnail» в файле /inc/func/posts.php воткнуть наперёд ещё одно условное выражение, которое для видеофайлов будет создавать миниатюру способом, функционально аналогичным приведённой в архиве http://yakuji.moe/wakaba/diffs.zip в файле wakaba.diff строчке 189 — вот только не на Перле, разумеется, а на PHP.¹

(Или я не прав?)

________

¹ К моей реплике присоединена звукозапись «Vanishing Horizon». Её автор — Jason Shaw. Источник звукозаписи — сайт http://audionautix.com/ её автора. Право на распространение звукозаписи даётся лицензией Creative Commons Attribution 3.0 Unported, на сайте указанной.

Если вы будете использовать загрузку аудио не по назначению (для обсуждения неких ваших проектов, так или иначе использующих звуковые файлы), она будет просто отключена до востребования.

Перспективы видео на 410чане можно обсудить в >>17371, эту нить угонять не надо.

В настоящее время по адресу https://iichan.hk/n/ сказано, что загрузка видеофайлов доступна только «в некоторых разделах», список которых даже не приводится там. Автор реплики https://iichan.hk/d/res/244600.html#245044 перечисляет не менее полутора десятков невидеофицированных досок Ычана, и у меня нѣтъ основаній не вѣрить этому списку.

Вот почему изложенные в реплике >>18670 инструкции по созданию WebM и MP4, дополненные в реплике >>18676 рецептом подключения субтитров, не достаточны для Ычана: мне следовало бы опубликовать также инструкцию по созданию GIF-файла из видеозаписи (потому что GIF, в отличие от WebM и MP4, принимают всѣ доски), и опубликую. Вот пакетный командный файл для Windows, создающий GIF из видеозаписи:

@echo off

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -an -sn -c:v libvpx-vp9 -crf 22 -b:v 0 -vf "scale=-1:%2:flags=lanczos" ibsrc4gif.webm

ffmpeg -hide_banner -i ibsrc4gif.webm -vf palettegen ibpalette4gif.png

ffmpeg -hide_banner -i ibsrc4gif.webm -i ibpalette4gif.png -lavfi "paletteuse=dither=bayer:bayer_scale=0" ibgif.%2.gif

del ibpalette4gif.png

del ibsrc4gif.webm

Пояснение термина «пакетный файл» (если кто не знает его) можно прочесть по адресу https://ru.wikipedia.org/wiki/Пакетный_фай?? в Википедии.

Пользователям невиндовых операционных систем перед употреблением придётся внести в текст команд ряд обычных отличий (заменить «%1» на «$1» и проч.).

Примерно как и в случае с репликою >>18670, я предполагал вызов из командной строки в форме «имяПакетногоФайла имяВидеоФайла.mkv 550 14:03 14:05.75», где «14:03» и «14:05.75» — отметки времени (откуда и докуда вырезать фрагмент из видеофайла «имяВидеоФайла.mkv»), но на сей раз третий параметр («550» в данном примере) — это не абстрактный показатель качества, а желаемый размер GIF-файла в высоту, выраженный в пикселах.

Выбран именно показатель высоты, так как почти всѣ анимешники (и оттого очень многие посетители имиджборд) хорошо знакомы с характерными значениями высоты кадра (1440 для QHD, 1080 для FullHD, 720 для «простого» HD, 480 для VGA) и с их влиянием на детализацию кадров видео. Цифры ширины были бы не так удобны, поскольку менее успели навязнуть в уме и притом ситуация устного счёта осложняется там наличием различных размеров кадра — не только 16:9, но также ещё 4:3, 2:1 («16:8») и проч.

Примерно как и в случае с репликою >>18670, величина высоты удобно записывается в название итогового файла, что в дальнейшем позволяет на глаз подбирать величину в зависимости от желаемого объёма — то есть можно, например, сравнить по размеру файл «ibgif.640.gif» (высотою 640 пикселов) и «ibgif.642.gif» (высотою 642 пиксела) и прийти к выводу, что первый меньше полуторамегабайтового предела (сейчас на Ычане у досок /vn/ и /c/ и /au/ и /mi/ действующего), а второй больше его, так что можно запустить команду ещё раз с промежуточным значением высоты (641) и надеяться, что тогда точно будет видно, какой файл грузить на Ычан.

Отличие влияния высоты GIF на объём от влияния качества WebM (или MP4) на его объём заключается в том, что большее качество всегда приводит к росту объёма (так что подбирать качество под объём позволяет простая дихотомия), тогда как зависимость объёма GIF от его высоты не так проста, и некоторые значения высоты (не слишком кратные изначальной высоте кадра) могут создать более «смазанные» пикселы, кодирование которых в GIF приводит (за счёт меньшей повторяемости элементов кадра) к росту объёма файла (в частности, GIF высотою 641 пиксел в примере из предшествующего абзаца легко мог по объёму оказаться больше своих аналогов с соседними значениями высоты, причём не только больше 640-пиксельного, что логично, но и больше 642-пиксельного, что парадоксально на первый взгляд).

В приведённом мною примере отметки времени «14:03» и «14:05.75» разделяют считанные секунды. Как-то так будет и у вас, потому что видео в GIF занимает много больше мегабайтов, чем в WebM, и впихнуть десятки и сотни секунд в GIF не получится, если только не уменьшить высоту кадра до очень небольшого значения, сильно жертвуя детализацией. Совершенно по той же причине высоту кадров всегда приходится делать меньше исходной, а не то объёмы GIFов размера FullHD легко получаются в итоге многодесятимегабайтовыми.

В приведённом мною примере отметка времени «14:05.75» содержит указание доли секунды («.75», что означает «три четверти»). Как-то так может оказаться и у вас в тех случаях, когда на экране происходит циклический процесс и оттого у изготовителя GIF есть шанс сделать последний кадр GIF похожим на первый кадр (а точнее — на такой кадр, который идеально предшествовал бы первому), чтобы анимация плавно зациклилась. Иногда этого не так просто достигнуть, когда в кадре периодических процессов несколько (например, когда слёзы в глазу у плачущей персонажицы имеют один период колебаний, а под глазом — другой период, вдобавок не кратный первому, а длина отрывка меньше наименьшего общего кратного двух периодов), так что поневоле приходится подбирать не идеальный кадр, а первый попавшийся сколько-нибудь сносный, и такой далеко не всегда можно отыскать точно на границе двух соседних секунд.

Третьею из важнейших проблем качества GIF на имиджбордах (причём, возможно, даже превосходящею небольшой размер и небольшую длину анимации) является ограниченность цветовой палитры 256 цветами — приём, который позволил разработчикам формата в конце восьмидесятых годов полагаться на LZW-сжатие данных, но который через тридцать лет представляется идейно устаревшим. Последствия этой ограниченности неприятны: никак нельзя полагаться на то, что стандартная палитра встроенного в FFmpeg GIF-кодировщика (которую я прилагаю к этой реплике в качестве иллюстрации) окажется сколько-нибудь близкою к тем цветам, которые наиболее часто используются в конкретном кодируемом отрывке аниме (и которые поэтому следует использовать в GIF-кодировании для того, чтобы отрывок выглядел сколько-нибудь нормально и гладко, то есть чтобы мешанина точек промежуточных цветов — мешанина, имитирующая нужный цвет, не попавший в палитру — не делалась раздражающе явною от большой разницы между этими промежуточными цветами). Вместо стандартной палитры необходимо всякий раз использовать специальную палитру, автоматически созданную на основе конкретного видеоматериала.

Ввиду этого однократный запуск FFmpeg и создание видеозаписи за один проход (что в реплике >>18670 и >>18676 было достаточно) для GIF-файлов представляется неприемлемым по итоговому качеству, а предлагаемый пакетный файл запускает FFmpeg три раза кряду: первая команда, руководствуясь указанными отметками времени и высоты, вырезает из исходной видеозаписи желаемый отрывок и применяет https://ru.wikipedia.org/wiki/Фильтр_Ланцоша для уменьшения каждого кадра до указанной высоты, вторая команда запускает на этом полученном отрывке палитрогенератор, третья команда создаёт GIF на основе отрывка видео (полученного на первом шаге) и подобранной (на втором шаге) палитры.

Этот подход к делу основан, главным образом, на рецепте http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html 2015 года, который я незначительно улучшил, вынеся получение уменьшенного отрезка видео в отдельный шаг. В рецепте 2015 года предполагалось просто вписать эту операцию в команду вызова палитрогенератора и затем в команду вызова GIF-генератора, но так как проматывание видеофайла к нужной отметке времени — это долгий процесс (иногда несколько десятков секунд), то мне показалось нелепицею повторять его дважды, а затем я заметил также, что создание промежуточного WebM в среднем качестве (CRF 22) слегка компенсирует эффект контраста, привнесённый фильтром Ланцоша, и оттого уменьшает объём итогового файла GIF.

Автор рецепта http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html сообщает также, что https://en.wikipedia.org/wiki/Ordered_dithering по алгоритму Байера не только устраняет проявления https://en.wikipedia.org/wiki/Colour_banding (появление монотонных цветовых полос на том месте, где в первоисточнике идут переливы цвета между оттенками, отсутствующими в палитре), но и уменьшает объём GIF (хотя в кадре появляется мешанина цветов, она не случайна, а с математическою строгостью выбирает в каждом месте наиболее подходящий из предопределённых узоров, имеющих согласно https://ffmpeg.org/ffmpeg-all.html#paletteuse равные размеры 8×8 пикселов и ввиду предсказуемости хорошо сжимаемых LZW-алгоритмом в GIF), тогда как принятый по умолчанию в GIF-генераторе у FFmpeg алгоритм «Sierra» устраняет узорчатость, но хуже передаёт разницу между оттенками цвета и притом (ввиду случайности и вызванного ею роста информационной избыточности) пагубно влияет на сжатие («it completely kills the compression of GIF»). Наглядно убедившись на опыте в том, что Sierra способна бесследно съесть небольшую разницу между цветовыми оттенками, когда те не настолько популярны в изображении, чтобы заслужить у палитрогенератора каждый по цвету в палитре (а именно таким цветом, например, в кадре у реплики >>19332 выкрашена левая дужка очков, которые носит Цубаса Курата: эту дужку мы видим только в небольшом углу его очков, на которые притом лёг блик от экрана, сквозь который дужка имеет вид, еле отличающийся по цвету), а также убедившись и в том, что байеровские узоры сжимаются лучше, я задал соответствующие параметры GIF-генератору: не только включил алгоритм Байера, но даже и снизил до нуля порог появления узорчатости (чтобы не засорять кадр искусственными границами между узорчатыми и неузорчатыми полосами, притом передвигающимися в ходе анимации, а покрыть вместо того весь кадр узорами 8×8 и дать зрению привыкнуть к наличию этих квадратиков).

Справедливости ради надо отметить, что рецепт http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html оканчивается серией наглядных примеров различного подхода к переводу иллюстрации в ограниченную цветовую палитру, но всѣ они отвратительно далеки от наглядности ввиду того, что первоначальное изображение само по себе содержит неестественные монотонные цветовые полосы (будучи, вероятно, кадром из недесятибитного аниме, павшим жертвою агрессивного видеосжатия).

Так как ограничение цветности является наиболее существенным и заметным ограничением GIF, то я не стал предусматривать в тексте команд никакого способа для экономии объёма файла за счёт дальнейшего уменьшения количества цветов в палитре: уродливые плоды такой экономии слишком заметны, так что уменьшение высоты кадра почти всегда следует предпочесть уменьшению палитры. Предложенный в рецепте http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html способ уменьшения объёма GIF путём искусственного снижения частоты кадров также показался мне дающим некрасивые результаты по отношению к аниме, так как частота кадров многих сцен в аниме и без того невелика, насколько это возможно, а тут они становятся и вовсе какими-то дёргаными.

Примерно как и в случае с репликою >>18676, получающуюся анимацию можно без труда снабдить субтитрами из файла-первоисточника, изменив всего одну команду простою допискою. В данном случае к «flags=lanczos» достаточно приписать «,subtitles=%~nx1» (непременно через запятую); для невиндовых систем аналогом «%~nx1» является, вероятно, опять же «$1». Всѣ оговорки из реплики >>18676 о том, что в таком случае исходный видеофайл не должен содержать спецсимволов в имени, справедливы и в этом случае (то есть много проще дать файлу простенькое имя наподобие «src.mkv», чем разбираться с тем, как у FFmpeg экранируется квадратная скобка или пробел в имени у источника субтитров).

Напоследок уместно подчеркнуть, и подчёркиваю, что указанный способ создания GIF универсален: он годится, разумеется, не для одних только тех досок Ычана, на которых WebM или MP4 не сделались ещё внедрёнными, но также и для других имиджборд в Интернете, лишённых поддержки WebM и MP4, но принимающих GIF и притом нередко ограничивающих размер GIF не таким строгим ограничением, каковы ычанские полтора мегабайта — следовательно, щедро допускающих более длительную анимацию или более крупный размер кадра в GIF.

Пособие https://trac.ffmpeg.org/wiki/Encode/VP9 оказалось рекомендующим чрезмерно подробные параметры вызова FFmpeg.

Действительность же вот какова: так как правка https://github.com/FFmpeg/FFmpeg/commit/2392da164a02e4e4f7e1b933018d14afcb13ddc1 была внесена 28 августа 2015 года, то FFmpeg создаёт WebM посредством кодека VP9 по умолчанию примерно с того же времени.

Соответственно, параметры «-c:v libvpx-vp9» можно исключить (потому что они подразумеваются в FFmpeg) из моих рекомендаций, приведённых в репликах >>18670 и >>19332.

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

Проще всего это сделать на примере WebM, для которого FFmpeg (по аналогии с >>19377) автоматически употребляет кодировщик Opus, так что остаётся только выбрать битрейт — например, 256kbps — и вписать в аналогичную >>18670 командную строку:

ffmpeg -hide_banner -i %1 -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm

Впечатывание субтитров в видеокадр достигается аналогичным >>18676 приёмом:

ffmpeg -hide_banner -i %1 -vf "subtitles=%~nx1" -ss %3 -to %4 -sn -crf %2 -b:v 0 -b:a 256k -tile-columns 2 -threads 8 ibvideo.%2.webm

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

Если искать наиболее наглядный пример такого идеала между имиджбордами околоычановского конгломерата, то с неизбежностью приходится торжествующе ткнуть пальцем прежде всего в Nowere.net (открывается как подраздел /tu/ верхней навигационной панели или по гиперссылке «туризм» из раздела «Общее» в левом фрейме на Ычане). Там поддерживается публикация видеозаписей в формате WebM, и не отвергается звук, и допускается размер файла до двадцати мегабайтов.

Не знаю, куда отправить, пощу здесь. Ссылка на пост будет дана в /d/ Ычана.

Данный патч к Вакабе 3.0.9:
1. позволяет пихать перловские регулярки в вордфильтр
2. Выводит причину бана в сообщении о бане
N.B.: причина бана является обязательным полем для заполнения при бане из Management Panel в Вакабе 3.0.9.

Диффы: http://yakuji.moe/wakaba/diffs.zip

Мотивация нововведений: мне надоела эта катавасия с "почему меня забанили"-тредами и "если мы будем говорить всем причину, то будет срач".

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

Полюбоваться на тестовую строчку при попытке отправить сообщение можно по адресу: http://yakuji.moe/wakaba/

Данный патч к Вакабе 3.0.9:
1. позволяет невозбранно тереть посты пользователей не заходя в админку, если в качестве пароля для удавления поставить модпасс.

Диффы: http://yakuji.moe/wakaba/diffs.zip

Мотивация нововведений: это патч в одну строчку, сделанный около года назад или больше, лол.

Чуть больше трёх недель тому назад (19 марта) автор реплики https://iichan.hk/d/res/244600.html#245388 счёл возможным в обстоятельствах запрета на загрузку звуковых файлов (MP3, Opus) появление таких видеофайлов (MP4, WebM), у которых звуковая дорожка будет содержать желаемый звук (например, Opus в WebM), а видеодорожка будет состоять из повторений одного и того же видеокадра (в качестве примера он упомянул обложку альбома) — такие повторения очень хорошо сжимаются видеокодеком, так что такая видеозапись будет, в общем-то, немногим хуже (неэффективнее) первоначальной звукозаписи (конечно, если видео со звуком вообще разрешено публиковать на имиджборде, то есть если не запрещён звук в видео).

По адресу https://github.com/pituz/webm-thread/wiki/Pro-tips#Создание-видео-из-статичной-картинки-и-музыки можно видеть, что та же идея посещала в позапрошлом (2016) году разработчика, действовавшего на Гитхабе под псевдонимом «Питуз», который предложил для решения её такой рецепт, который может быть скорректирован под нынешние обстоятельства (восторжествование видеокодека VP9 и аудиокодека Opus) и избавлен от некоторых чрезмерных настроек (изменение длины GoP и высоты кадра), после чего принимает следующий вид:

ffmpeg -hide_banner -loop 1 -r 1 -i %1 -i %2 -ss %3 -to %4 -crf 7 -b:v 0 -b:a 256k -pix_fmt yuv420p -tile-columns 2 -threads 8 -shortest ibaudio.webm

Пользователям невиндовых операционных систем перед употреблением придётся внести в эту команду ряд обычных отличий (заменить «%1» на «$1» и проч.).

Предполагается, что команда для удобства лежит в пакетном файле и оттого вызывается в форме «имяПакетногоФайла имяКартинки.png имяЗвуковогоФайла.mp3 14:03 23:15», где «14:03» и «23:15» — отметки времени (то есть откуда и докуда надо вырезать звуковой фрагмент из файла «имяЗвуковогоФайла.mp3»).

Если же такие отметки не нужны (то есть если звук следует помещать в видеоролик весь целиком), то тогда и параметры «-ss %3 -to %4» не нужны в команде.

Параметр «-r 1» (снижение частоты кадров до одного кадра в секунду) очень важен, потому что более чем на порядок уменьшает количество кадров и тем преизрядно ускоряет кодирование.

Напоследок уместно упомянуть (и упоминаю), что содержимое файла https://github.com/pituz/webm-thread/blob/master/message.md как бы говорит нам о том, что сам Питуз не имел времени воспользоваться собственными наработками, так как к концу того же (2016) года вынужденно совершил, как он сам пишет, «покидание сосача», вынужденный к тому двумя обстоятельствами — во-первых, внедрением платного увеличения предельного размера публикуемых файлов (которое умаляло и обесценивало прежний интерес Питуза к достижению максимальной эффективности в рамках общего для всех прокрустового ложа), а во-вторых, конфликтом с администрацией, по каким-то своим соображениям стёршей некий «ОП-пост» (вероятно, текст начальной реплики обсуждения-видеосборника) и гиперссылки на рецепты Питуза по созданию видеороликов.

Не патч, но шпилька в сторону Ычана: в Вакабе 3.0.9 кнопка "назад" на странице ошибки так-таки берёт адрес из (HTTP_)REFERER, а не линкует обратно на доску. Я могу понять, что это может привести в милый цикл, если ошибка возникнет при чём-то сильно глобальном, что не позволяет запустить админку, но это не повод её не включать.

>>19606

Вообще-то там «href="javascript:history.back();"» напрашивается, хотя бы ради демонстрации ранее заполненной (на предыдущей странице) формы ввода.

>>19607
Вообще, если мне не изменяет память, это обсуждалось примерно четыре года назад в /d/, в том числе предлагалось и явоскриптовое решение. Хотя, может то было больше в контексте 404-страниц. Уже не вспомню всю переписку.
В любом случае, делать только жабоскриптовую версию, ящитаю, неправильно, реферрер хотя бы через <noscript> оставить бы. А то любители посидеть с совсем-совсем отключенными скриптами у нас таки есть.

>>19612

Ну тогда «href=" чего угодно " onclick="history.back(); return false;"».

Изложенные в рецепте >>19601 параметры «-pix_fmt yuv420p», по-видимому, полезны и во всех предшествующих рецептах, потому что без них FFmpeg может попытаться создать WebM с таким форматом пикселов, который в Firefox восприниматься не сможет (например, в десятибитном цвете) — или, может быть, сможет, но только в какой-нибудь новой последующей версии.

Кроме того, больше двух недель тому назад правка кода https://github.com/FFmpeg/FFmpeg/commit/0dc11d8bbd470db89fbc17b7434e992c9129b310 привела к появлению в FFmpeg поддержки кодека AV1, которому википедическая статья https://en.wikipedia.org/wiki/AV1 пророчит появление также внутри контейнеров WebM. Но до тех пор, пока это появление не состоится (или, вернее, не возымеет широкой поддержки в стабильных последних версиях браузеров), никаких готовых рецептов для командной строки вызова FFmpeg, порождающего видео AV1, я сочинять не стану.

А попробуйте присобачить к «Вакабе» какую-нибудь HTML5-рисовалку вместо «Shi», чтоб в современных браузерах работала.
У этого действительно есть шанс взлететь.

>>19634
Если мне не изменяет память, владелец нынешнего слепого телефона нечто подобное уже делал, логичнее пнуть его.

>>19640
То есть, если затык в "привинтить конкретную рисовалку к Вакабе" — я в деле, но выбирать/писать рисовалки есть кандидатуры много лучше, проверенные временем. И читающие этот раздел.

>>19641
Так возьми фейхоа и прикрути к вакабе. Там в принципе прикручивать нечего, нужно лишь подкорректировать POST-запрос.

>>19642
А ссылку на сорцы?

>>19647
Я думаю, что >>19642-кун/тян имел(а) в виду https://github.com/MyonMyon/feijoa, на форке которой https://github.com/f2d/dfc работает, если не ошибаюсь, 2draw.me, в котором рисуют участники треда "Слепой телефон" в /b/ Ычана.

>>19727
Я уже связался в f2d и получил свежайшие исходники, прямо с источника, но вплоть до третьего числа скорее всего не начну работать.
c: Perl

Ведро 4.4, Хром. Изображения в ОП-постах раскрываются вот так. На них текст налезает.

>>19746
Пф.
Ведро 8, хром и мишный браузер, изображение в новой вкладке.

>>19747
А на полной версии сайта >>19746

>>19748
А, в мобильной версии вообще яваскрипта нет, кажись.

Всѣ послѣднія версіи FFmpeg (по меньшей мере, от версии 4.0 и до сборки 8 мая включительно) отчего-то начинают генерировать невыносимо большое количество байеровской узорчатости (и даже никак не объяснимой по Байеру хѣрни) в том режиме «bayer_scale=0», который я рекомендовал выше.

По-видимому, это какой-то баг FFmpeg, потому что до этого таких проблем не было.

Единственный известный мне способ избежать его — поставить «bayer_scale=1» вместо этого, но и этот способ не идеален (возникают те границы между узорчатыми и неузорчатыми полосами, которых при нуле не было).

По поводу бага >>19788 два замечания.

Во-первых, он касается только анимированных GIFов, то есть замена значения «bayer_scale» (временная, для обхода бага в FFmpeg до того момента, когда разработчики исправят его) потребуется только в рецепте >>19332.

Во-вторых, по-видимому, баг в FFmpeg появился ввиду исправления ошибки https://trac.ffmpeg.org/ticket/4443 без последующего исправления ошибки https://trac.ffmpeg.org/ticket/6813 или другой аналогичной. Другой причины в багтрекере у FFmpeg я не мог найти.

Отдельно подчёркиваю: тот обходной путь, который изложен в реплике >>19788 и уточнён в реплике >>19790, всего лишь маскирует главную проблему: в FFmpeg 4.0 сломан генератор GIFов.

(И маскирует не слишком умело. При «bayer_scale=1» не так много сверхзаметного мусора, но всё равно видно какое-то чрезмерное трепетание узора в кадре там, где его не должно быть.)

Поэтому моя рекомендация сводится не к тому, чтобы применять этот обходной путь (хотя я и изложил его), а к тому, чтобы вообще не использовать FFmpeg 4.0, а оставаться на предшествующей исправной версии — FFmpeg 3.4.2 (или, по крайней мере, пользоваться только ей для создания GIFов). До тех пор, пока четвёртый FFmpeg не исправят.

>>19729>>19634
В общем, всё очень мило запиливается за ночь, есть только проблема. В том числе безопасности.

Нам надо как-то достать картинку с рисовалки на сервер. И так как всё рисование происходит на стороне клиента, то на сервер, потенциально, могут подсунуть чёрт знает что.
Я вижу три решения:
1. Хранить, как сейчас, временные файлы в /tmp/, удалять всё что старше часа и обмазать это разрешениями на чтение/запись. Соответственно, обеспечение безопасности на совести Администрации. Или проще - проверять файл на то, что это вообще png, но тогда при постинге проверка будет идти повторно.
2. Таскать туда-сюда картинку в base64, как она таскается сейчас дудлятором. Проблемы две: во-первых, всего картинку придётся протащить четыре раза: с рисовалки на сервер, с сервера на форму ответа (и как картинку и как поле формы ответа), и с формы ответа обратно на сервер. При этом на втором шаге картинка невозбранно подменяется на что угодно, даже не base64.
3. Хранить картинку где-то в памяти браузера и показывать её оттуда же. Всё ещё возможна подмена как в 2, но нет таскания файлов туда-сюда. Но надо будет переписывать форму ответа специально под этот случай, по-моему.

Я сейчас сделаю 1 с проверкой на png. 3 мне сделать не хватает теоретических знаний.

>>19991
http://yakuji.moe/wakaba/oekaki.diff
Содержит диффы к jfc.js и milf.js из https://github.com/f2d/doodle-mutator/tree/master/doodle, но не сами эти файлы.
Наверное, можно ещё посмотреть, почему при загрузке файла холст слетает в выравнивание по левому краю, как красиво убрать сохранение/загрузку чтобы кнопок не было, но при перебое питания можно было восстановить картинку, и ещё что-нибудь (например, передавать параметры чтобы интерфейс на русском), но я лучше спать. Благо, серверная часть в основе своей сделана.

Кажется, я нашёл что-то более Щи-подобное. https://github.com/funige/neo
Другой вопрос - кому это надо.

Вот такой закреп, когда ещё и дублируется id на странице - это очень плохо, пнятненько?

>>20791
Stick-тред не скрывается с доски, просто кто-то забыл его ещё и hide сделать.

>>20792
Сейчас лучше, но я был бы признателен, если бы там было хотя бы три последних ответа. Зайти в репорт-тред чтобы увидеть, что репорт уже есть не очень приятно. А если кто-то пользуется куклоскриптом, и привык отправлять с нулевой?

>>20793
Алсо, я не уверен, что это надо на каждую страницу лепить, достаточно на нулевой.

Закрытые треды невозможно скрыть. Или что-то в этом роде.

Упоминавшийся в предшествующих репликах >>19788 и >>19790 и >>19791 баг FFmpeg мне удалось наконец донести до разработчиков FFmpeg, по адресу https://trac.ffmpeg.org/ticket/7613 он изложен и помечен словами «Reported by user Mithgol».

Тамошний анализ ситуации показывает, что проблема затрагивает только режим «bayer_scale=0», а всѣ мои рассуждения в реплике >>19791 про «какое-то чрезмерное трепетание узора в кадре» — это нормальное последствие упомянутых в реплике >>19788 «границ между узорчатыми и неузорчатыми полосами, которых при нуле не было» (и которые меняются от кадра к кадру).

Полностью подтвердилось изложенное мною в реплике >>19790 подозрение «по-видимому, баг в FFmpeg появился ввиду исправления ошибки https://trac.ffmpeg.org/ticket/4443 без последующего исправления ошибки https://trac.ffmpeg.org/ticket/6813 или другой аналогичной»: баг возник именно вследствие правок https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=aba926e7d654b6dfab680130c92e571ee9a956f0 (которые по адресу https://trac.ffmpeg.org/ticket/4443 упомянуты в качестве исправляющих).

Но, естественно, у меня-то это было простым подозрением: не располагая Linux-машиною для запуска «git bisect run», я никак не мог это подозрение проверить. Если бы не разработчики, то установить истину было бы очень трудно.

Теперь с удовольствием дожидаюсь исправления, предвкушая возможность невозбранного (не останавливаемого прежним ощущением ущербности) использования FFmpeg 4.x, в котором поддержка AV1 и прочие ништяки.

Ну и, конечно, остаётся небезынтересный вопрос о том, как это так получилось, что правку https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=aba926e7d654b6dfab680130c92e571ee9a956f0 приняли в октябре прошлого года, а проблему больше года никто не замечал, пока не пришёл Mithgol the Webmaster и не начал ейной мордой в харю тыкать, как завещал великий Чехов.

Думаю, что не ошибусь, если предположу, что покрытие тестами в FFmpeg недостаточно — или что, по крайней мере, режим «bayer_scale=0» тестированием не охвачен.

Багъ >>20993 двѣ недѣли остаётся безъ малейшаго движенія, такъ что затаивать дыханіе въ ожиданіи его исправленія я бы въ ближайшее время не сталъ.

Безрадостное впечатление >>21018 дополнительно усиливается тем обстоятельством, что предшествующая проблема https://trac.ffmpeg.org/ticket/4443 (которую-то починили по принципу «нос вытащил — хвост увяз» и породили нынешнюю испорченность кодирования GIFов) простояла незакрытою с 7 апреля 2015 года по 7 ноября 2017 года, то есть два года и ещё семь месяцев ровно.

Соответственно, если рассуждать по аналогии, то никак нельзя исключать того, что совет >>19791 (не использовать четвёртый FFmpeg для создания GIFов, оставаться на версии FFmpeg 3.4.2) останется актуальным до середины 2021 года.

Запаситеся терпением, короче говоря.

>>20791>>20793
>Разлепили
Лол.

Я так понял, что до прикручивания рисовалки руки пока так и не дошли.

Так что давайте пока обсудим «Быстрый ответ». Прикручивание этой функции на «Ычане» и доработка на «410чане» в целом одобрены, но есть вопрос по реализации.
Скажем, на «4чане» форма быстрого ответа вылезает в качестве отдельного окна, которое можно свободно двигать по экрану, а на «Доброчане» и в отдельных скриптах она появляется под сообщением и «прибита» к нему.
Какая реализация по вашему мнению удобнее? И что требует меньше сложного кода/последующей нагрузки на браузер?
(Этот вопрос касается обоих сайтов, потому что будем прикручивать одинаковую реализацию.)

>>21756
По количеству кода и сложности проще под постом делать. На самом деле, главное отличие — для плавающей формы нужен ЖС для тягания формы и определения позиции формы при открытии. С другой стороны, при статичной форме нельзя добавлять её в одно место в страничке. Так что в целом разница минимальна.
По-хорошему, нужно совместить оба варианта: изначально форма появляется под постом, но можно нажать кнопку/потянуть за шапку и она станет плавающей. Но опять же, если идти от обратного и делать максимально просто, то можно вообще сделать плавающую форму на HTML+CSS, которая будет работать и без JS, от которого там будет только добавление ссылки на пост по onclick.
Посему, вопрос нужно ставить не плавающая или статичная форма, а делать хорошо или просто.

>>21757
Почему нельзя? Форма хранится в переменной, при нажатии на кнопку ищетсяна странице, предыдущее вхождение убирается из дерева, вставляется под новым постом.

>>21758
Я как раз про то, что в одном неизменном месте дерева нельзя держать, придётся теребить дерево под каждое сообщение.

>>21759
А. Ну это да.
Вообще, что до ЖСа - на Автобусе, ЕМНИП, уже есть вское resizable и draggable, так что если бы не было нужды делать и под Ычан тоже, то плавающая форма была бы очевидным вариантом. А вот насколько много ЖСа готов Мод-тян чтобы мы впихнули в Вакабу - вопрос (где публичная репа, блджад?).

>>21756
Я однозначно за отсутствие плавающего окна, на мобильных устройствах будет вообще кошмар, на ПК оно будет вечно куда-то теряться и уезжать, что и происходит в известных реализациях.
Вопрос: нужно ли скрывать форму создания треда за кнопкой "создать тред", как это реализовано в кукле? Так будет гораздо меньше снайперов, если вообще будут. Еще можно сделать эту кнопку и вверху, и внизу страницы, и тогда не придется скроллить. Реализовать это не сложно, и кроме того, чисто с технической точки зрения проще родную форму ответа вырезать со своего места вверху страницы и вставить под пост, значит сверху она пропадет, значит нужна кнопка, чтобы ее вернуть.

>>21762
Категорически против таскания одной формы. Там, где есть быстрая форма, часто начинаю писать в быстрой форме, потом, когда текст получился достаточно объёмным, не закрывая её, перечитываю всё в растянутой основной форме.

>>21763
Можно же вернуться к основной форме, нажав кнопку, и весь текст в ней сохранится.

Еще вопрос: оставлять ли правила и прочий подвал в форме быстрого ответа?

>>21767
Разумеется, нет.

>>21762
Считаю, что прятать форму создания треда за кнопкой не нужно, ибо это неудобно.

>>21769
Типичный пользователь создает в лучшем случае 1 тред на 100 своих постов, и то этот 1 тред может быть промахнувшимся мимо треда ответом. Один раз нажать кнопку не так уж сложно, зато точно будешь знать, что делаешь.

>>21756
Сделано. Особо не тестировал, но вроде работает. Скажите, если будут замечания.
Для копипасты в консоль или на сайт: https://github.com/WagonOfDoubt/iichan-extensions/blob/master/dist/escaped/iichan-quick-reply.min.escaped.js
Для тестирования в качестве юзерскрипта: https://github.com/WagonOfDoubt/iichan-extensions/blob/master/dist/userscript/iichan-quick-reply.user.js
Скорее всего в ближайшее время буду вносить косметические правки.

>>21772
С индекса невозможно быстро ответить в тред, потому что неправильно заданы параметры key (и dummy, но последнее, насколько я знаю, не учитывается) у капчи. Соответственно, предлагаю при нажатии на кнопку капчу обновлять в соответствии с параметрами.

Ну и, версия на Чиоичан будет?

>>21773
dummy — это такой древний костыль, чтобы браузер капчу не кешировал. У самой капчи (и фапчи здесь) есть GET-параметр, определяющий доску, для которой генерится капча (здесь это board={{boardId}}) и сессия на сервере, таким образом капча полученная для одной доски не применима для другой (это важно разрулить, если будете делать ответы на попупы).

Второй древний костыль — это параметризация процедуры создания нового поста или треда. Осуществляется при помощи скрытых полей в пост-форме (здесь это <input type="hidden" name="board" value="{{boardId}}" /> и <input type="hidden" name="replythread" value="{{(threadId || 0)}}" />), в которые пишутся id доски и id треда или ноль, если это запрос на создание нового треда.

Третий древний костыль — это защита от спам-ботов при помощи кучи полей, скрытых разными способами (type="hidden" или display:none;), имеющие разнообразные, в том числе и пустые, значения, которые трогать, равно как и выкидывать эти поля из формы, не надо.

>>21776
Что-то сейчас глянула по второму костылю: у Автобуса в дополнение имеется параметризация самого урла вида /board.php?{{boardId}}, её тоже надо учитывать.

Юзернейм, чем объяснять очевидности человеку, который занимается этими двиглами уже года четыре, вы бы скрипт починили. Тем более что второй и третий пункт в этой реализации ну никак не проявляются.
>dummy — это такой древний костыль, чтобы браузер капчу не кешировал.
Таки никто не мешает инвалидировать капчу при появлении нового поста в треде, в теории. Исходники-то закрыты.
>это важно разрулить, если будете делать ответы на попупы
Поддержка костылей не является самоцелью администраций обоих ресурсов, насколько нам известно, и такого нет в ТЗ. Как и попапов в нынешних движках.

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

>>21778
>нет в ТЗ
Так и ТЗ никакого нет пока, только вынесли на обсуждение.

>>21773
Починено.
Еще в видео плеере справа от "[Свернуть видео]" добавлена галочка для включения звука по-умолчанию. По-моему, она совсем не мешает, и это будет хорошим компромиссом для тех, кому не нужно отключение звука.
В hide-threads заменил кнопку в каталоге с [┼] на [+]

Шел 2019 год, а на Ычане так и не осилили Вакабу переписать. Все тормозит, ну как так можно?

>>21801
Потому что допиливают для модераторов, а не для постеров.

Можно наконец отключить автофокус на поле сообщения при загрузке страницы?
Для этого всего-то нужно убрать строчку в wakaba3.js:
nya4.focus();
В функции set_inputs().
Жутко бесит же. Нажал F5 чтобы обновить тред - и страница скроллится в самый верх.

>>21890
неистово ычую
надо в /d/ ычана написать

>>21890
Пользуюсь Ычаном 10 лет, впервые о таком слышу.

>>21890
Кстати, а возможно ли это как-нибудь отключить на стороне клиента (не ломая при этом остальные тамошние скрипты)?

>>21893
Кукла это отключает. Пока расширения не поломались, не осознавал, с чем приходится мириться тем, кто ей не пользуется.

Почините, пожалуйста, дату, я с сырноида в /b/ зайти не могу.

>>21896
Куклу ради этого ставить точно не буду.
А вообще — надо будет проверить, сработает ли, если в юзерскрипте написать что-то вроде

nya4.focus = function(){}

>>21897
Так вернули же уже, не?

В связи приделыванием «Быстрого ответа» ещё назрел вопрос по десигну.
Очевидно, пора хотя бы часть этих текстовых [Ы] заменить на пиктограммы.
В общем, приделайте к «Ычану» значки с «410чана». Как минимум скрывалку/раскрывалку тредов и собственно «Быстрый ответ» (надо сделать как на картинке).
Возьмите примерно такую же реализацию: через добавление пустого прозрачного файла на саму страницу и показ значка через background в CSS. Сами значки будут 410чановские (синяя версия для «Футабы»), чтобы людям проще было ориентироваться в интерфейсах обоих сайтов.

>>21901
На Автобусе нет Буричана, под него какие значки будут?

>>21902
*Гурочана, то есть.

>>21903
Можно красные попробовать.

>>21901
Не понел, уже запилили быстрые ответы или как?

>>21902
Там свг, филл тебе в помощь.

>>21901
Что насчет скрытия/раскрытия? Плюсик тоже взять свгшный, или [x] лучше сохранить?

>>21906
>Как минимум скрывалку/раскрывалку тредов

Сделано. Так же добавлен ❌ для закрытия видео (надпись оставлена).

>>21911
А закрытие формы быстрого ответа с тем же ❌ нельзя сделать?

>>21913
Зачем, когда она закрывается нажатием на ту же кнопку быстрого ответа, с которой вызывается?

>>21914
Это неинтуитивно.

Ычую закрытие формы крестиком в углу самой формы. Так везде сделано.

Ладно, сделал так.

>>21918
Вот так красота.

Кстати эта лабуда совместима с любыми стилями, благодаря тому, что в SVG установлен fill=currentColor, то есть иконки будут того же цвета, что и текст.

>>21920
А теперь сделайте так, как вас просили в ТЗ, пожалуйста.

>>21923
Так нет никакого ТЗ, или я что-то упустил?

>>21901
>через добавление пустого прозрачного файла на саму страницу и показ значка через background в CSS
Излишне и костыльно. Такой способ не позволяет изменять параметры svg и теряется весь смысл в нём. Лучше инъектить непосредственно svg, желательно либо в контейнере, либо просто указывать класс, что позволит одной строкой в css менять цвет всех глифов. К тому же тот файл, что сейчас на Чиочане можно разрезать на элементы, чтобы не мучать позиционирование, а указывать айди нужного глифа.

>>21926
В скрипте именно так и сделано.

>>21924
Так тяжело нить почитать? >>21901

>>21926
Если бы был нужен инлайн-SVG, то так бы и просили.
Он не нужен, его не просили. Такую реализацию принимать не будут.

>>21928
Аргументация, зачем вообще тогда нужен svg, будет?

>>21931
Я заменил здесь ПНГ на СВГ потому, что это векторный формат, который смотрится одинаково при любой плотности пикселей. Лично я отказался от этих чудовищных костылей с засовыванием исходного кода картинок в исходный код страниц, ибо это раздувает размер файлов и затрудняет читку исходников. Ещё было соображение, что так люди могут легко поменять себе значки на вообще другие.

Упорное желание сделать не так, как просили, с последующим флудизмом с требованием «аргументов» просто задерживает и без того неторопливые изменения на «Ычане».

>>21932
> Лично я отказался от этих чудовищных костылей
Чудовищными костылями является как раз то, что продвигается. Обусловлены они при этом лишь тем, что так было сделано в движке 2008 года автором, который не подразумевал использование svg.
> ибо это раздувает размер файлов
Напомню, речь идет о скрипте. В HTML-файлах никаких svg не хранится это раз, а если бы и хранились, то только ускоряли бы загрузку страницы это два.
> Ещё было соображение, что так люди могут легко поменять себе значки на вообще другие.
Так в любом случае одинаково легко заменить эти значки. Более того, так иконки намного легче стилизовать, добавив им фон или перекрасив в любой цвет. Продвигаемый способ кусабы 2008 года такой свободы не дает.
> сделать не так, как просили
Сделали так, как правильно. Лучше сразу делать нормально, чем "как просили", а потом переделывать.
> просто задерживает и без того неторопливые изменения на «Ычане».
Придирки к готовой работающей реализации, в полной мере решающей все поставленные задачи, замедляют этот процесс. Ничто не мешает запилить готовую реализацию хоть сейчас. Упорное желание заставить переделывать уже сделанное потому что ятакскозал - это просто манипуляция ради манипуляции, и банальное неуважение к чужому труду. Быть или не быть злобными Буратинами - это исключительно ваш выбор.

>>21932
Так аргументация и требуется для выяснения причин такого решения с последующей дискуссией о плюсах и минусах того или иного способа.

Во-первых, самое главное, элементы управления сообщения можно и нужно добавлять на стороне пользователя (что и сделано в текущей реализации ещё не внедрённых быстрых ответов и, внезапно, уже внедрённого скрытия). В связи с этим, сама страница не будет жрать больше трафика и толстеть без включенных скриптов, а чтобы поменять кортинку-иконку, достаточно один раз поменять её в скрипте. Тут, правда, возникает вопрос, что и после чего пришлось чистить от мусора; подозреваю, что это связано с Чиочаном и его архивом, и, следовательно, тем, что на Чиочане при сохранении в архив сохраняется не голая страница, а текущий стейт со всеми включенными скриптами. Если так, нужно исправить.
Во-вторых, люди смогут поменять значки на свои, если, опять же, обернуть в контейнеры. Тогда просто скрывается svg и впендюривается своя.
В-третьих, если что и не нужно, так это костыль в виде прозрачного гифа. Есть inline-block, которому можно задать нужный размер. То есть всем кнопкам достаточно задать контейнер с display: inline-block.

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

>>21933
Что ж ты так пассивно-агрессивно? Просто нужно лаконично объяснить, почему именно так лучше.

>>21936
Представь, что ты строитель, и построил заказчику дом, и тут он с видом эксперта поясняет, что я же хотел дом не из кирпича, а из пластилина, а чтоб стены не обрушились поставь прозрачные трубочки от сока, давай переделывай.
На вопрос "почему так" отвечает, что в кирпичный дом нельзя заходить с левой ноги, ставить пластиковые окна, и вообще он своей гравитацией притягивает Луну, что влияет на приливы и отливы, из-за чего труднее чистить крышечки от йогурта. И вообще, ты своим флудом только замедляешь строительство.
Так и тут, приводятся аргуметы: "раздувает размер файлов" (нет), "затрудняет читку исходников" (на сайте с табличной версткой, ага), "так люди могут легко поменять себе значки на вообще другие" (а тут им сделать то же самое религия не позволяет), заключая тем, что заткнись и делай что говорят, что ты время тянешь.

>>21937
Нет, заказчик вам деревянный дом заказал, а вы впариваете ему небоскрёб, патамушта нибаскрёп круче. Сделал что-то не то, и теперь капризничает.
Причём смысл всей инициативы был в прикручивании «быстрого ответа», а значки шли вдовесок. Сделали ли бы базовую реализацию, как просили (причём вполне прокатило бы без прозрачных гифов, если можно просто HTML-блоки нужных размеров вставить), дальше можно было бы обсуждать улучшения. Теперь уже майские выходные из-за этих порожних амбиций и флуда полностью протеряны в плане разворачивания этих функций хотя бы на тесте, а могли бы уже с рабочим «быстрым ответом» сидеть.

>>21939
Если Д'Артоньян несет дичь, причем чем большую дичь несет, тем больше он Д'Артоньян, это не повод идти у него на поводу. Пост ясно >>21932 показал, что отсутствует даже понимание о том, о чем идет речь, не было приведено ни одного валидного аргумента, кроме своего понимания фен-шуя. Причем убедть Д'Артоньяна в чем-либо невозможно, посему флуд прекращаю.
Вы можете набираться ума хоть до следующих майских, все, кому нужен этот функционал, и так пользуются им последние 10 лет.

>>21940
Добрее быть нужно. Заказчик тоже человек.

> — Вот вам ТЗ, сделайте.
> — hurr я сделал что-то другое не по ТЗ durr какие у тибя аргументы hurr дартаньян durr

>>21942
Ну, про аргументы спросил я и потом расписал >>21936, почему в принципе можно принять уже предложенную реализацию.

>>21940
Ну так кто ж этому д’Артаньяну виноват, что он объективных и убедительных аргументов не привёл никаких, а просто трясёт субъективно нравящейся ему реализацией костылей? Единственный аргумент тут построен на допущении, мол, вот я сделал, а больше тут никто не сделает.
И главное: зачем этот д’Артаньян спорит со мной, если я только объявы размещаю, лол? Вы сделали не по ТЗ, так что это продлевает затуп. Могут в итоге и принять ваши костыли, я не знаю.

>>21944
Я не знаю, почему д’Артаньян решил вместо убедительных аргументов упираться в на то, что так было в "ТЗ" и что ему нравится такая реализация костылей (которую по-хорошему и на 410чане следовало бы убрать, но уж так тому и быть).
Насчет аргументов в пользу реализации здорового человека, которые уже привели в паре простыней выше, их можно повторить еще раз:
1) Значки будут поддерживать любую уже существующую тему оформления. Значки легко: перекрасить, добавить фон, фильтры, анимацию, что угодно. Не нужно делать несколько разноцветных SVG под каждую тему оформления, о чем говорилось в "ТЗ". Если делать по строго "ТЗ", то нужно зачем-то добавлять файлы на все цвета радуги, раздувая объем скриптов и создавая лишнюю работу. То, что здесь при наведении на значок background меняется с ./icons/red/icons.svg на ./icons/blue/icons.svg весто изменения свойства fill или color - это дикий костыль. Вообще, файлов с разными цветами можно было бы и с background'ом избежать.
2) В background кнопкам уже нельзя стилем добавить тот же background в виде цвета или градиента - иди рисуй новые значки, к тому же отпадает половина CSS-свойств, хочешь немного изменить их вид - иди рисуй.
3) Люди могут легко поменять себе значки на вообще другие. (Почему кем-то подразумевалось, что нет - непонятно)
4) Зачем в "ТЗ" говорилось про
> через добавление пустого прозрачного файла на саму страницу
не понятно, очевидно из сентиментальных чувств к древним костылям. Ведь прозрачная гифка не нужна ни в какой реализации, что через inline svg, что через background. Если делать по такому "ТЗ" - значит добавлять костыли ради костылей.
Напоследок, хотелось бы пожелать, чтобы разместитель объяв не считал всех идиотами, и допускал бы, что если человек принимает то или иное решение, на это есть определенные соображения, а не "упорное желание сделать не так, как просили", и вместо выставления абсурдных требований в ультимативной форме попытался бы выяснить и понять, почему сделано так, а не иначе.

>>21945
Сразу видно, что с заказчиками не работал практически. Нужно не убеждать, что твоё лучше, чем в ТЗ, а объяснять, почему в ТЗ хуже, чем у тебя. Это немного разное.
Просили сделать как в ТЗ только потому, что оно уже сейчас точно работает и было время для обкатки на длинных выходных, а вот потом уже как хотите допиливайте.

Разговаривайте друг с другом как люди, а не как упёртые бараны. Тогда и обсуждение продуктивнее выйдет, и агрессии не образуется.

>>21945
> чтобы разместитель объяв не считал всех идиотами, и допускал бы, что если человек принимает то или иное решение, на это есть определенные соображения, а не "упорное желание сделать не так, как просили", и вместо выставления абсурдных требований в ультимативной форме попытался бы выяснить и понять, почему сделано так, а не иначе.
Вам там ничего не жмёт, лол? Вот написали вам ТЗ, за которым стояли определённые соображения. Не нравится? Ну, мимо бы прошли. Или сначала бы покритиковали. Нет, вы посчитали автора идиотом и выставляете ему (лол, это ведь его запрос, вообще-то) ультимативные требования, срётесь в тредике с рандомными людьми, обзываетесь. Но д’Артаньян, конечно, кто угодно, но не вы. Вы у нас Наполеон I Бонапарт.
>раздувая объем скриптов и создавая лишнюю работ
Лол, это сование исходного кода файла целиком раздувает объём скриптов. А создаёт дополнительную работу ситуация, когда мало отредактировать в графическом редакторе картинку и тупо кинуть на сервер, но надо выдёргивать её исходный код и каждый раз совать в скрипт, от которого зависит часть работы интерфейса. И CSS ради новых цветов всё равно надо каждый раз редактировать, если вам не нужны кнопки цвета текста (а они нужны цвета гиперссылок, лоло).
Как удобно и прогрессивно! Ради этого надо один костыль (я ведь не спорю, лол) на другой костыль менять, прямо облегчение. Впрочем, с этим будут ковыряться жалкие идиоты-заказчики, а не наш Наполеон.

>>21948
Текущая реализация на 410чане ужасна и запиливать ее не нужно ни в коем случае. Захотите заменить ее на нечто нормальное - обращайтесь.
Если вам нужен был svg-спрайт отдельным файлом, а не добавляющийся в тело страницы - то надо так и сказать, а не тыкать носом в "ТЗ", описывающее то, что делалось в 2008 году с оглядкой на IE6 не подразумевая никаких svg.
Если нужен отдельный файл, это значит, что вместо
<svg><use xlink:href="#iichan-icon-reply"></use></svg>
будет
<svg><use xlink:href="/icons/isons.svg#iichan-icon-reply"></use></svg>
И заметьте, решение данной проблемы никак не затрагивает никаких background'ов.
В ТЗ описываются цели и задачи, а не детали конкретной реализации. В изначальном посте не говорилось ничего про отдельный файл. Если все делать строго по тому посту, то можно зафигачить эти svg в виде data uri в CSS и полностью ему соответствовать. Ответ без вопроса задачу никак не описывает.
> А создаёт дополнительную работу ситуация, когда мало отредактировать в графическом редакторе картинку и тупо кинуть на сервер
Вообще-то, этого в любом случае мало. Нужно как минимум прогнать файл через оптимизатор для веба, и проверить их еще и вручную, так как Inkscape или любой другой редактор выдает в исходном коде черти что, и использовать в спрайте не оффсеты, а раздать значкам читаемые айдишники.
> Как удобно и прогрессивно!
Да, без сарказма и иронии, такой способ - наиболее правильный.
> CSS ради новых цветов всё равно надо каждый раз редактировать
Но не надо создавать десятки одинаковых файлов, отличающихся лишь цветом.

>>21949
Вам из предыдущих задач для «Ычана» должно было быть понятно, что чем меньше вы всякого лишнего мусора добавляете на страницу, тем лучше.
Если вы можете хотя бы само СВГ в отдельный файл сунуть, а не размазывать его прямо на страницах, это уже похоже на что-то более вменяемое.

>>21950
Изначально говорилось, что: минимальными должны быть и предлагаемые правки вёрстки самих страниц.
Что и было сделано: скрипты содержали в себе все необходимое, включая недостающий CSS и HTML, и тут вдруг добавление еще одного элемента на стороне клиента помимо всего уже имеющегося - это почему-то лишний мусор. Это не разу не очевидно, ну да ладно.
icons.svg кидается в корень сайта, правится если что руками путем копипасты содержимого path из исходного файла.

>>21772
В svg не хватет ’xmlns:xlink="http://www.w3.org/1999/xlink";’

Сделайте, пожалуйста, версию без сворачивания основной формы ответа при использовании формы быстрого ответа.

>>21772 Путь к .svg файлу сделать бы куда-нибудь в /extras

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

>>21964
Форма ответа на Ычане и на оранжевом - две разные вещи. Там загрузка картинок осуществляется полностью через JS, показывается превьюшка, и блобом загружается на сервер. При использовании для загрузки стандартного инпута с type="file", поменять его значение программно невозможно.
Использование одной формы на страницу было самым простым и логичным решением. Никакой вырвиглазности не наблюдалось бы, будь форма ответа скрыта по умолчанию, как это и сделано в приведенных примерах.
В данном случае для синхронизации выбранного изображения между формами пришлось использовать хак с клонированием ноды, который, как пишут, может не работать (да и не должен) во всех браузерах. Тем не менее, в последнем фаерфоксе и хроме оно работает.
Синхронное редактирование форм включается только на странице треда, но при первом вызове формы быстрого ответа содержимое основной формы копируется в нее в любом случае (юзкейс: увидел форму создания треда, начал писать, понял, что ошибся и хотел ответить в тред, и нажал быстрый ответ).
>>21963
Перемещено.
>>21961
Исправлено.

>>21965 Не работает в /o.

>>21975
Починил. Вроде бы.

В хромоте ссылкота на сообщение не вставляется, похоже.

Пуклоскрипт даже выключенный ломает инъекцию кнопащик.

>>21978
https://dscript.me/de/

>>21979
Так в том и дело, что это показывает неоптимальность алгоритма детекта страницы, раз оно об малейшее изменение ломается. Очевидно, что можно стотысячный костыль в пуклу вставить, но, во-первых, оно должно работать само, если в стороннем скрипте нет принудительного выпиливания нативных скриптов, во-вторых, оно будет ломаться об другие скртпты, поддержкой которых никто давно не занимается.

>>21980
В ФорчанХ, например, стоит кнопка "отключить нативные скрипты". И с ними оно не работает.
Скрипты сайта не должны пытаться отключать скрипты юзеров или пытаться как-то под них приспособиться.

>>21981
Так я о том и говорю. Сейчас ситуация такая, как если бы 4Х отключал нативные скрипты фактом своего существования, а не настройкой отдельной.
Подозреваю, кукла добавляет свой элемент в корень страницы, а скрипт быстрой формочки ищет первый из некоторых, находит элемент куклы и пытается найти в нём посты, ничего не находит, а дальше не ищет.

>>21982
И сейчас куклоскрипт ломает скрипты сайта своим существованием.
Не вижу проблемы.

||iichan.hk/extras/iichan-quick-reply.min.escaped.js

А было время, когда никакие блокировщики на Ычане были не нужны…

>>21978
Если речь про то, что кукла отключается нажатием на "включить/выключить Dollchan", и кнопка быстрого ответа не появляется, то так и должно быть. Встроенные скрипты детектят само наличие куклы, а не то, в каком она состоянии. Любой юзерскрипт можно отключить в один клик настройках расширения.

Исправлено:

• ошибка в хроме, из-за которой ссылка на пост не вставлялась в форму автоматически.
• копирование текста из формы быстрого ответа в форму создания треда, когда форму быстрого ответа переключали на другой пост
• дефолтное поведение по нажатию на номер поста, прописанное в wakaba3.js: нажатие на номер поста приводило к вставке ссылки на пост в верхнюю форму, если это делалось со страницы доски, а не треда, то сначала осуществлялся переход на страницу треда, а затем вставка ссылки в эту форму. Теперь же ссылка вставляется в форму быстрого ответа, при этом форма быстрого ответа не переносится со своего текущего положения, в отличие от нажатия на 💬, которое перемещает форму ответа на свой пост. Если форма быстрого ответа не открыта, то на странице треда ссылка на пост вставляется в основную форму, на странице доски форма быстрого ответа появляется так же, как при нажатии на 💬.

Никакие другие сообщения об ошибках воспроизвести не удалось. Кукла тоже работает как надо, не ломается и ничего не ломает.

>>21985
Мне кажется, указывать исключения в виде конкретных юзерскриптов со в скрипте нативном — моветон. Пусть лучше Штёпа выпиливает в своём скрипте кнопки Иичана, чем Иичан будет выпиливать свои кнопки всем с куклоскриптом.

>>21986
Примечание по кукле: при ctrl+f5 с выключенной куклой не появляются кнопки в первый раз.

>>21964
Еще один минус двух разных форм:
При ответе с доски в форму быстрого ответа, если неправильно ввести капчу, то при возврате назад всё содержимое формы пропадает: наверху-то была форма создания треда, и вернуть его никак нельзя. В изначальной реализации все сохранялось бы.
Ну и синхронизация поля выбора файла между формами не работает на всяких андроидах, как и ожидалось.

>>21989
Следующий шаг — аякс-постинг и попапы вместо редиректов.

>>21990

Мрачно предполагаю, и не вполне безосновательно, что для реализации этой идеи потребуется перемѣнить и сёрверную часть кода, а не одну только клиентскую.

И так как сёрверная часть кода не открыта, а закрыта, то — — —