420873535

Правильнее будет использовать querySelector.

var el = document.querySelector(".myclass");



getElementsByClassName - не работает на мобильных платформах.

Про этот способ я не совсем понял. Но когда мне нужно сделать свой дизайн для социальных кнопок поделиться то я делаю так. С начало я подключаю к сайту блок Поделиться от Яндекса https://tech.yandex.ru/share/ с теми кнопками которые мне нужны. Дизайн на данный момент можно выбрать любой.
Затем в подключенном скрипте можно настроить этот блок таким способом.

new Ya.share({
	element: 'yaShare',
	elementStyle: {
		'type': 'button',
		'quickServices': ['vkontakte', 'facebook', 'gplus']
	},
	onready: function(instance) {
		$(instance._block).find('a.b-share__handle').each(function() {
			var el = $(this);
			el.removeClass();
			
			if (el.find('span').hasClass('b-share-icon_vkontakte')) {
				el.find('span').remove();
				el.append('<b class="icons-vk"></b>');
			}

			if (el.find('span').hasClass('b-share-icon_facebook')) {
				el.find('span').remove();
				el.append('<b class="icons-facebook"></b>');
			}

			if (el.find('span').hasClass('b-share-icon_gplus')) {
				el.find('span').remove();
				el.append('<b class="icons-google"></b>');
			}

			if (el.find('span').hasClass('b-share-form-button')) {
				el.find('span').remove();
			}
		});
	}
});

Из кода видно что после того как блок от Яндекса загружен в нем ищется и удаляются span'ы c дизайном от яндекса и вместо них добавляются блоки с теми классами с которыми вам необходимы.

Очевидно, Bootstrap v4 - это первое что приходит в голову.
Еще недавно нашла Flex Layout Attribute, уж больно интересен этот концепт избавления html от кучи перечислений классов. Однако потестить пока не успела, но может вам пригодится.

border-radius: 0 0 50% 50%;

https://codepen.io/AndrewHaze/pen/VPmRJB

Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

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

В 3 простых шага:
1. Делаете так, чтобы блок всегда прилипал к верху страницы: position: fixed
2. Отслеживаете нужное событие (например, проверяя расстояние до верха страницы при скролле:

$(window).on('scroll', function(){ if ( $(window).offset.top > 200){ console.log("> 200"); })

3. При выполнении условия из пункта 2 добавлять класс из пункта 1 к нужному элементу $('selector').addClass('fixed');

Что такое физические и CSS-размеры?

CSS-размеры - это плод Вашего воображения, есть разные единицы, которые можно использовать при верстке. Они сильно отличаются: читать
физические размеры тоже не совсем верная формулировка. Я так понимаю речь о том, что пользователь имеет размер дисплея в см, при этом расширение экрана может быть совершенно разное при одинаковых размерах в см.
Допустим мониторы c разрешением fullHD (1920х1080), при этом на экране 22'' и на экране 32'' размер блока в см будет в реальности разный (измеряя линейкой), при том что в px или в % он одинаковый. Связывающее звено, это плотность пикселей ppi: читать

Почему верстальщику проще "растянуть" макет под большую ширину?

Тот же вопрос. А почему?

ПС: Если Вы ищите идеальное решение - его нет. Дизайнеру и верстальщику надо знать и понимать как себя ведет графика на разных диагоналях дисплея при одинаковых расширениях. Надо понять что такое пиксель, что такое сантиметр, что такое соотношение сторон и т.д. Это целая наука, тут одной фразой не опишешь. Надо много чего прочитать на эту тему. Я считаю, что web-дизайнер, обязательно должен немного знать html и css. Это как бы отдельная профессия и отдельный специфический набор знаний. Тут "умею рисовать в фотошопе" слишком мало. Как и для дизайна визиток или буклетов, надо понимать, что такое СMYK, что такое цветоделение, какие типы печати бывают, какие типы бумаги и т.д.
Самый простой способ все это понять и освоить - больше общаться с верстальщиком, при чем желательно с хорошим. У меня жена дизайном занимается, пока не научил css и html получал го..но psd. Потому что надо понимать, что можно сделать, что просто, что сложнее, что будет динамическим, что фиксированным. Очень много нюансов.

https://github.com/Okazari/Rythm.js + demo

1. Всегда предоставляйте потенциальному заказчику план ваших действий - это может быть иерархический список работ с различной зависимостью между собой в формате таблицы Excel с формулами и условиями (для смены отображения: фон, цвет и т.д) в ячейках.
2. Там, где цена за данный вид работ неизвестна (будет известна после выполнения предшествующих пунктов работ) - ставим нолики в трудозатратах.
3. Обязательно пишем сноску под таблицей: "ВНИМАНИЕ: работы с нулевой стоимостью выполняться не будут."
4. После этого можно подготовить проект в GanttProject не добавляя туда работы с нулевыми трудозатратами и экспортировать в PDF.
5. Два документа: xls+pdf - отсылаем как ТКП на согласование клиенту и прикрепляем к договору.
6. При необходимости, модифицируем договор с помощью доп. соглашений для выполнения тех этапов, стоимость которых стала известна и которые необходимы клиенту.

По этапам разработки веб-сайта: здесь.

Во всех других случаях - нет смысла работать с теми, кто не хочет работать.

Если хотите по клику на кнопку, то вы кое что забыли:

document.querySelector('button').addEventListener('click', function() {
        slideout.toggle();
});

И slideout.js надо подключать перед инициализацией скрипта.
В настройках jsfiddle Frameworks & Extensions поставьте nowrap in
jsfiddle.net/Lshamfyw