Никита Геннадич

Я бы предложил поискать на LinkеdIn кого-то из бывших работников и делать это через него.

Однако насколько я знаю FB до крайности политизированная компания и все такие кейсы обычно заканчиваются ничем если у вас нет какого-то админресурса в ЕС или одной звёздно-полосатой стране.

Возможно кому-то будет полезен ещё вариант блокировки элемента по фрагменту класса. Это часто применимо, так как всё чаще встречаются CSS-модули с постоянными префиксами.

site.com##[class^="newsTicker_container"]

В этом примере будут заблокированны все элементы в классе которых есть подстрока newsTicker_container

Также полезно знать, что модификатор hat-text работает не только непосредственно на сам блок, а на все дочерние, т.е. например

##.div-item:has-text("Текст")

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

Ощущение, что отвечающие выше особо даже не думали прежде чем ответить.

С помощью эмодзи, конечно, можно сделать выдачу симпатичнее, но надо понимать, что тег description также используется для поиска и сопоставления запроса. И теперь подумайте много ли людей используют эмоджи при поиске.

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

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

В некоторых случаях можно обойтись использованием объекта location.state

Это немного криво, но уж лучше чем ничего. Идея в том, что с помощью этого объекта есть возможность передать информацию, когда вы переходите откуда-либо с помощью navigate:

import { useNavigate } from 'react-router-dom'
...
const navigate = useNavigate()
useEffect(() => {
 navigate('/new-page', {state: { from: 'old-page' }})
}, [])

А уже в нужном месте можно проверить откуда был совершён переход:

import { useLocation } from 'react-router-dom'
...
const { state: locationState } = useLocation() // Естессна, как и всех хуки это всё внутри компонента
console.log(locationState ?.from)

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

Если ничего не менять в вашей вёрстке, на ум приходит только вариант вот такой (добавить блок map-inner внутрь map):

.content {
  height: 100vh;
}
.map {
  max-height: 100vh;
  background-color: #eee;
}
.map-inner {
  margin-top: 8px;
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 50%;
  background-color: #23fe12;
}

Но это будет работать только если у вас нет необходимости задавать в абсолютных единицах высоту .content, как это было сделано в вашем примере. А также если у вас отступ от верхней части не меняется (поскольку тут используется абсолютное позиционирование).

А лично я бы вовсе по другому сделал. Кмк тут логичнее сделать вот так:

<div class="container">
	<div class="row">
    <div class="map"></div>
		<div class="col">
			<div class="content">content</div>
		</div>
	</div>
</div>

.container {
  max-width: 400px;
  margin: 0 auto;
}
.row {
  display: flex;
}
.col {
  flex: 1 1 60%;
  border: 1px solid #aaa;
}
.content {
  height: 1000px;
}
.map {
  height: 100%;
  max-height: 100vh;
  position: fixed;
  top: 0;
  bottom: 0;
  right: 0;
  left: 50%;
  background-color: #eee;
}

И от этого уже отталкивался бы...

Во всех больших проектах, в которых я работал, использовали первый вариант.

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

Что касается моего мнения, так БЭМ это в принципе шизофрения, эти нижние слэши делают из стилей мусор.

Я вот тоже озаботился данным вопросом... Оказалось не так всё просто как может показаться на первый взгляд.

Практически во всех обсуждениях для того чтоб дёргать WinAPI советуют использовать решения на основе node-ffi, а она, в свою очередь, требует наличия на компе всего необходимого для ребилда node-gyp, а это - питон и visual studio (несколько гигов). Есть ещё варианты типа win-audio, но там те же грабли шизофреничные — для компиляции нужен node-gyp со всеми вытекающими...

Короче, тут один энтузиаст переписал node-ffi на расте, и там все эти костыли не нужны, хотя поставить компилятор G++ всё же придётся, но он работает без танцев с бубном и весит всего сотню метров.

Я для себя сделал вот такое, возможно кому-то пригодится: https://github.com/Psychosynthesis/AudioManager

Судя по всему это какой-то баг хрома, вроде как давно известный (предполагаю этот: https://bugs.chromium.org/p/chromium/issues/detail...), но с ним ничего не делают...

Причём проблема именно в хроме, и конкретно с атрибутами filter | fill | stroke | clip-path | mask и т.п. Во всех таких примерах используется конструкция вида fill="url(#toncloutLogoGradient)", которая ссылается на айдишник linearGradient. Но что-то решать этот баг никто не торопится.

Подписался на вопрос, буду рад, если кто-то поделится решением.

Погуглите в сторону css-свойства:

mix-blend-mode

Кажется это именно то що вам надо, но на старых браузерах может не работать.

Возможно кому-то ещё пригодится ещё один простой вариант очистки селектора:

document.getElementById(SELECT_ID).innerHTML = "";

Я столкнулся по сути с той же проблемой, хотя я пишу без всяких сборщиков, так что код попроще для понимания, так что возможно кому-то ещё может пригодится мой подход.

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

{
	...
	"background": {
		"scripts": ["queryParamsRemover.js"]
	},
	"browser_action": {
		"browser_style": true,
		"default_icon": "icons/panelicon.png",
		"default_title": "Eraser",
		"default_popup": "panel/panelMenu.html"
	},
	...
}

Соответственно, код с логикой panelMenu у меня подключался просто через тег в теле panel/panelMenu.html:
<script src="panelMenu.js"></script>

Естессна, никакие импорты внутри panelMenu.js не работали, вылетала ошибка Uncaught SyntaxError: import declarations may only appear at top level of a module. Очевидно, при попытке импортить что-либо в queryParamsRemover.js ошибка была аналогичная.

Как выяснилось, решения у данной проблемы два:
1. В файл panelMenu.html скрипт встраивается с атрибутом type="module":
<script src="panelMenu.js" type="module"></script>
После этого внутри panelMenu.js уже работают привычные импорты (кому-то хватит и этого, полагаю).
Далее, чтобы импорты заработали и в основном background-скрипте (у меня это queryParamsRemover), придётся немного изменить подход. Решение (как по мне) выглядит несколько коряво, но именно так предлагает делать официальная документация: https://developer.mozilla.org/ru/docs/Mozilla/Add-...

Итак, нужно изменить манифест:

"background": {
	"page": "background.html"
}

А уже в этом самом background.html вставлять основной скрипт всё с тем же атрибутом module:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <script type="module" src="queryParamsRemover.js"></script>
  </head>
</html>

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

Добавьте больше электролитов на питание усилителя и блютут-модуля. Можно и без диода даже.

Выкиньте его в помойку и никогда не покупайте конденсаторные микрофоны, подключающиеся по USB, это просто бред.

Конденсаторный микрофон это штука требующая фантомного питания. А чтобы подключить его по USB, помимо прочего нужен ещё и АЦП. Какой АЦП будет в безделушке за пару тысяч? Правильно - отвратительный.

Т.е. если вы хотите себе действительно качественный конденсаторный микрофон - желательно покупать отдельно конденсаторный микрофон и звуковую карту с фантомным питанием и XLR входом.

Есть, конечно, и очень крутые конденсаторные микрофоны с USB, в которых и фантомное питание нормально сделано и АЦП качественный, но они стоят денег столько, что в этом просто нет смысла.

Хотите USB-микрофон - покупайте электретный и это будет хотя бы приемлемо (потому что там не будет лишнего шумящего DC-DC).

Да, припаивайте оба канала на один - на здоровье.
Вот схемы: https://chipinfo.pro/elements/acoustics/jack_pinou...
Случаев когда у вас в разных каналах будут строго противофазные сигналы, практически не бывает, разве что специально такие сигналы формировать.

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