Aetae

Как вариант:

про кодеки для веба:
https://habr.com/ru/post/442020/
если прочтете статью полностью, то вопрос "какие видеокодеки лучше использовать" отвалится сам по себе, более того варианты кодеков для веба и как их применять в теге актуальны на сегодняшний день, разве что поддержка AV1 значительно расширилась (но вот аппаратная в зачаточном состоянии)

по части почему долго - предполагаю, потому что сначала грузит видео, а только потом его начинает воспроизводить, то с данной вводной инфой гадать остается, вероятно у вас mp4/H.264 и так-называемый moov-атом находится в конце контейнера, а не в начале, и сафари начинает воспроизводить файл только когда до него доберется. Но это голая теория в ответ на достаточно размытый вопрос

принудительно перетащить moov-атом в начало mp4/H.264 файла можно с помощью ffmpeg:

ffmpeg -i input_video_file.mp4 -vcodec copy -acodec copy -movflags faststart output_video_file.mp4

const isOpen = Boolean(rules.isDefault || rules.child?.length);

1. Узнать требования к никнейму
Официальная документация требует:
Символы: A-z (регистр не важен), 0-9 и "подчеркивание"
Длина: 5-32
2. Описать регулярку:

const validTelegramNickname = /^[A-Za-z\d_]{5,32}$/;

function copyToClipboard(value) {
    var prev_focus = document.activeElement;
    var area = document.createElement('textarea');
    area.value = value;
    document.body.appendChild(area);
    area.focus();
    area.select();
    area.setSelectionRange(0, 99999); /* For mobile devices */
    document.execCommand('copy');
    document.body.removeChild(area);
    if (prev_focus) {
        prev_focus.focus();
    }
}

Работает везде - Firefox, Chrome, Safari

Надим Закиров подсказал ответ на вопрос:

для того чтобы избежать остановки таймеров, на странице, где работает скрипт запускаешь бесконечное воспроизведение mp3-файла с тишиной. Лично мне это помогает избежать заморозки.

<video style="position: fixed; left: 30px; bottom: 30px; z-index: 99999; height: 55px; width: 300px; border-radius: 100px;" controls loop name="media">
  <source src="https://site.ru/fon.mp3" type="audio/mpeg">
</video>

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

interface PostAttachVideo {
  type: 'video'
  attach: AttachVideo
}

interface PostAttachAudio {
  type: 'audio'
  attach: AttachAudio
}

type PostAttach = PostAttachAudio | PostAttachVideo

function isAudio(attach: PostAttach): attach is PostAttachAudio {
    return attach.type === 'audio';
}

песочница

Мой собственный ответ после изучения темы и чтения иностранных коллег будет таким:

Технология была многообещающей и интересной на старте. Для ее поддержки гугл даже придумал отдельную спецификацию HTML Imports: https://w3c.github.io/webcomponents/spec/imports/i... (можете не ходить, там 404), что позволяло подключать однофайловые компоненты прямо в документ так:
<link rel="import" href="my-component.html">
Классно же да?

Но технология не приобрела популярности, возможно так как была слишком простой и понятной, а именно в это время на пик славы вышел npm, gulp и вот это всё. В моду входила непонятная магия, утрата контроля над кодом и всякие оптимизаторы позволявшие сделать для одного слайдера на главной страницы бандл в полтора, а иногда 2-3 Мб. кода, и всё это без всяких там jQuеry.
Ребята одумались и убрали спецификацию HTML Imports, предлагая разбивать компоненты на 3 отдельных файла - js, css и html с шаблоном. Причём js надо было подключать на странице, css тоже, а html должен был загружать по задумке создателей уже в само js. Такой подход позволял резко усложнить работу с web-components и сделать код снова неуправляемым, но было поздно - технология уже уступила позиции конкурентам.
Конечно это был сарказм, если кто-то не понял.

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

Короче технология по задумке хорошая, но на практике не применимая, поэтому широкого распространения и не получает.

Максимально близкое к желаемому это Discriminating Unions

interface ModelOptionRange {
  value: [ number, number ];
  range: true;
}

interface ModelOptionValue {
  value: number;
  range: false;
}

type ModelOption = ModelOptionRange | ModelOptionValue;

function check(v: number, cond: ModelOption): boolean {
  if (cond.range) {
    // тут cond точно типа ModelOptionRange
    const [ min, max ] = cond.value;
    return (min <= v && v <= max);
  } else {
    // а тут ModelOptionValue
    return v === cond.value;
  }
}

песочница

Book['author']
Но если вам нужно чтобы по программе гуляли разные куски интерфейса, то лучше разбить его на куски

interface BookAuthor { ... }
interface BookPrice { ... }
interface Book {
  id: number,
  author: BookAuthor,
  price: BookPrice
}

Оба разработчика, когда работают в своих ветках, должны поддерживать актуальное состояние, т.е. периодически вливать (merge) dev в свою ветку.

Поэтому, прежде чем делать pull request, разработчик B должен вмержить dev в свою ветку. В случае, если при этом возникнут конфликты, он решает их внутри своей ветки. И только после того, как он удостоверится, что эта ветка содержит все коммиты из dev и все тесты проходят, можно делать pull request в dev.

d=document.querySelector("#bg");
d.onclick = function(e) {
  if (e.target !== this)
    return;
 alert("click")
}

 Попробуйте так

desktop.ini