Леонид Князев

Outline это контур элемента с внешней его стороны, то есть сразу за border. В отличие от border он никак не влияет на элементы, их ширину и расположение. Ключевое слово inset в свойстве outline: inset 100px green; устанавливает этот контур в виде псевдотрехмерной рамки за счёт осветления правой и нижней границ и затемнения левой и верхней относительно указанного цвета. Ширина 100px, цвет зелёный.

Баг создаёт свойство outline-offset: -125px;, которое задаёт смещение контура. При положительном значении контур будет расширяться во все стороны. А при отрицательном будет сжиматься внутрь элемента.

Спецификация CSS Basic User Interface Module Level 3 в статусе рекомендации говорит о том, что контур элемента со свойством outline-offset при отрицательном значении не должен становиться меньше, чем двукратная вычисляемая ширина контура. То есть если в примере у нас размеры элемента 100x100 пикселей и контур задан у нас шириной 100px, то при outline-offset: -125px; он должен сжаться внутрь элемента на 125px со всех сторон, а спецификация визуально ограничивает сжатие до outline-offset: -50px; (по 50px внутрь с каждой стороны элемента). То есть контур должен просто сойтись вместе со всех сторон, образуя квадрат в нашем случае и насколько больше не ставь отрицательное значение, больше он сжиматься не должен. Но реализация в браузерах не учитывает это поведение и выдаёт непонятные фигуры, если отрицательное значение слишком большое.

https://www.w3.org/TR/css-ui-3/#outline-offset


Поведение при отрицательном outline-offset должно быть как на гифке. Если дальше уменьшать значение, ничего меняться не должно.

(Все это дико не академично, не корректно и воообще, но должно быть понятно):

Процедурный подход: есть последовательность команд. Каждая из них может содержать последовательность команд.

возьми_кофемашину();
налей_воды_в_кофемашину();
нажми_кнопку();
подставь_кружку();
вылей_кофе_в_кружку();
наслаждайся();

ФП - акцент на действии. Одни действия влекут за собой другие.

наслаждайся(
    своим_кофе(
        которое_сделала_кофемашина(
            в_которую_налили_воды())))

ООП - акцент на объектах. Любое действие совершает конкретный предмет

есть кофемашина;
есть кружка;
есть ты;

ты.имеешь(кружку)
кофемашина.имеет(кружку)
кофемашина.поехали();
ты.возьми_свою_кружку();
ты.наслаждайся();

$a=4;
$b=10;
$z= $a*$b;

if ($a && $b > -1) { 
    echo $a-$b;
}
elseif ($a && $b < 0) {
    echo $a * $b;
}    
elseif ($z < -1) {
    echo $a+$b;
}

Скачать полный набор шрифтов?

Я бы, на вашем месте, для начала, выучил предназначение языков программирования. JS (А вы сейчас говорите именно про "браузерный" js), и, в частности, библиотека jQ работает на КЛИЕНТЕ В БРАУЗЕРЕ. Она НЕ МОЖЕТ и НЕ ДОЛЖНА по своей сути работать с файловой системой сервера. Если уж вам нужно это сделать, выполняйте асинхронный запрос с помощью jQuery и тащите данные с сервера.

Я делаю так

mount.cifs //198.168.220.37/d$ /home/zolt/mnt/prod_d/ -o user=user,pass=password,dom=domain

Где же оно обоюдовыгодное?

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

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

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

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

Как вам такой взгляд на ваше предложение?

Фреймворков в целом, которые достигли должного уровня популярности и народного признания - не так уж много (если говорить о PHP-фреймворках).

Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

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

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

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

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

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

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

Адрес начинающийся с двойного слеша будет использовать протокол, по которому загружена страница верхнего уровня
Используется это, для того чтобы не заморачиваться, где будет вставлен твой сниппет, так как политика безопасности для https требует чтоб все подресурсы так же загружались по https (браузеры имеют право даже вообще не грузить http ресурс на https странице)
А если страница загружена по http - то незачем тратить ресурсы сервера на шифрование, а время и ресурсы клиента на дешифровку

Резюмируя:
<img src="//site.ru/img.png">
на https странице будет работать как <img src="https://site.ru/img.png">
а на http странице как <img src="http://site.ru/img.png">