Johny Smith

1. А еще когда открываешь - разблокируется :)

2. Это никак не называется:

This beautiful Smart Cover protects your iPad Pro screen. Open it and your iPad Pro wakes up. Close it and it goes to sleep. Available in a variety of colors that match your other Apple accessories.

Элегантная обложка Smart Cover из высококачественной кожи защищает дисплей iPad Pro. Откройте обложку, и iPad Pro выйдет из режима сна. Закройте её, и устройство снова «уснёт». Выпускается в разных цветах, которые прекрасно сочетаются с другими аксессуарами Apple.

3. в корпусе айпада находится геркон

датчик Холла

brookhong.github.io/2014/04/28/keycast-on-windows.html

Это означает проверку доступности функционала в браузере и эмуляция этого функционала, если он не доступен. Вот на примере requestAnimationFrame():

// shim layer with setTimeout fallback
window.requestAnimFrame = (function(){
  return  window.requestAnimationFrame       ||
          window.webkitRequestAnimationFrame ||
          window.mozRequestAnimationFrame    ||
          function( callback ){
            window.setTimeout(callback, 1000 / 60);
          };
})();


// usage:
// instead of setInterval(render, 16) ....

(function animloop(){
  requestAnimFrame(animloop);
  render();
})();
// place the rAF *before* the render() to assure as close to
// 60fps with the setTimeout fallback.

Тут подробнее о примере

Почему бы и нет, если дизайнер подготовит на выходе не просто проект в Corel Draw, а папку с assets, где уже находятся все необходимые изображения (в svg или переведенные в png), то мне, как верстальщику, такой вариант был бы приемлем.

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

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

Вы перепутали строку поиска поисковой системы и форму оформления вопроса на тостере?

https://ru.wikipedia.org/wiki/Nofollow
https://support.google.com/webmasters/answer/96569...
https://yandex.ru/support/webmaster/controlling-ro...

Roboto Mono (см. гугл-фонтс)

• прикладное API различных операционных систем - разное. Если бы API было полностью одинаковое, то тогда операционные системы отличались бы только UX, набором софта и утилит, т.е. вместо Linux/Windows/BSD мы бы имели только Linux в разных дистрибуциях или только Windows в разных дистрибуциях. Ну т.е. по сути одну операционную систему, т.к. раз мы сейчас говорим о разработке прикладного софта, то нас интересует прежде всего API для прикладных приложений;
  
• т.к. API различных ОС отличается, требуется создание уровней абстракции, которые нивелируют эти различия. В других ответах уже достаточно примеров, я бы вспомнил например о разделителях в именах файлов;
  
• дополнительные уровни абстракции нередко сокращают доступное API, т.к. в большинстве случаев невозможно реализовать самому то, что нет в API какой-то из интересующих ОС. Следовательно, приходится оставлять только те интерфейсы, которые так или иначе есть везде;
  
• т.к. абстрагированные интерфейсы из пред. пункта более аскетичны, ими сложнее пользоваться, они дают не все возможности, соотв. какие-то задачи уже нецелесообразно решать кроссплатформенным кодом на базе этих асбтрагированных интерфейсов, проще написать несколько вариантов для разных ОС;
  
• оба предыдущих пункта - как достаточно успешные попытки сделать абстрагированные интерфейсы, так и наоборот, написание платформозависимого кода для каждой нужной платформы - удорожают разработку. Везёт только в случаях, когда абстрагированные интерфейсы уже есть и достаточно хорошо выполняют свою задачу, как например Asio. Или хорошие кроссплатформенные стандартые API вроде OpenGL, что делает возможным писать кроссплафторменные игры.
  
• разработчику ПО не нужно удорожание разработки там, где это не принесёт ощутимой выгоды.
  

Да, как бы, ничего не мешает писать один С++ код для множества платформ. Почти весь мой трудовой стаж связан именно с разработкой кроссплатформенных игр. Я работал с несколькими (самодельными и не очень) движками и имею свое собственное детище, прекрасно и однозначно собирающееся на 5 целевых платформ (Win, Mac, Linux, ios, Android), к которым без труда можно добавить и консоли, и новые платформы.

Нет, вру, не без труда. Попотеть над слоем абстракции придется. Но попотеть придется только над ним, все остальное заведется само, т.к. изначально написано в стандарте C++, без расширений под конкретные компиляторы, и с применением ряда очень важных для кроссплатформенности подходов.

Кроссплатформенность подразумевает решение ряда вопросов, которые и выливаются в слой абстракции над операционной системой. Эти вопросы, зачастую, решать никто не хочет. Несколько раз встречал такое сам и еще мне рассказывали о том, как тот или иной движок сперва был только под конкретную ###, а потом решили портировать на @@@. Оказалось, что компилятор, которым всегда и собирали движок, нашпигован расширениями языка, которые конечно же все пользовали на 100%, и при смене компилятора ни один файл исходников не остался без доброй сотни ошибок. Т.е. переписывать надо было ВСЁ.

Mercury13 хорошо рассказал про Unicode пути к файлам. Drakonoved правильно подметил про разделители путей к файлам. Максим Гришин очень хорошо напомнил про порядок следования байт. Это все и есть часть этого ряда вопросов.
У каждой платформы есть свой API, которого не будет на другой платформе. Но на другой платформе будет свой API, со своими именами и схожей функциональностью. И работу с API надо абстрагировать от универсального кода.
Еще, на одной платформе у тебя может быть разомкнутый главный цикл обработки сообщений (Win), а на другой - замкнутый (Android). Надо подстраиваться. GUI везде разный, надо подстраиваться. Сама структура приложения на одной платформе может быть монолитной, а на другой - композиционной. Графические и звуковые API могут быть и кроссплатформенными, однако простоты использования это им не прибавляет. Инициализация все равно будет платформозависимой.
На самом деле даже в рамках работы на одной платформе надо соблюдать ряд правил, чтобы иметь возможность из одного кода получать и 32-битное приложение, и 64-битное тоже. Об этом неплохо написано на сайте разработчиков PVS-Studio.

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

Ну или так: store.steampowered.com/app/431960/Wallpaper_Engine

windows7themes.net/en-us/how-to-use-dreamscene-in-...

Вот список расширений хром, которые использую при проверке верстки:
https://i.imgur.com/GAtlnSl.png

В том числе есть и линейка ("Page Ruler")

Либо убрать justify-content: space-between; у блока .content.
Либо скриптом добавлять пустой блок в самый конец, это уже не раз обсуждалось на Тостере.