Знание css html – HTML и CSS — зачем их нужно знать и почему познания в PHP и MySQL нужны, но в гораздо меньшем объеме — Вебджем.рф

Содержание

Часть 1. HTML / Habr

Вашему внимание предлагается достаточно большой отрывок статьи «Levels of HTML knowledge», написанной Роджером Йоханссеном 30 Мая 2006 года.

Прим. переводчика: Изначально я опубликовал этот пост в виде юмористических выдержек из трех статей, написанных тремя разными авторами и озаглавленных схожим образом: «Уровни владения HTML», «Уровни владения CSS» и «Уровни владения Javascript». Что, конечно же, было довольно глупой затеей. Осознание допущенной ошибки пришло через 5 минут и два минуса к посту и карме. Исправляюсь. Перевод «Уровней владения CSS» ждите завтра.

Уровень 0

Xэ–тэ–мэ–чаго?

Люди на этом уровне никогда не сталкивались с HTML, кроме как по ошибке, например, когда случайно открывали HTML-версию электронного письма в текстовом режиме. Эти люди не работают в веб-индустрии, и никогда не будут, поэтому у них нет ни причины, ни желания подняться выше нулевого уровня.

Типичное высказывание:

Уровень 1

HTML? Это такие штучки для того, чтобы делать текст жырным или курсивом?

Эти люди пользуются Интернетом достаточно давно и догадываются о том, что происходит за кулисами просматриваемого ими в данный момент веб-сайта. При попытке что-либо опубликовать в сети самим они беспомощны без какого-нибудь WYSIWYG-редактора. Это может быть Photoshop, Dreamweaver, Frontpage, или редактор, встроенный в CMS, которой им сказали пользоваться.

Люди, занимающиеся поддержкой содержания веб-сайта, зачастую находятся на этом уровне мастерства, а некоторые даже утверждают, что нет никакой надобности стремиться подняться на ступень выше. Многие визуально-ориентированные дизайнеры прочно застряли на этом уровне по своему собственному желанию, часто защищая свой выбор следующим: «Никто в печатном мире не редактирует PostScript-код вручную, так почему же в сети должно быть по другому?» К сожалению, многие менеджеры проектов также редко забираются выше первого уровня.

Уровень 2

Странички, которые я делаю в Macromedia Dreamweaver’е, отлично работают в Internet Explorer’е. Зачем мне вообще смотреть на этот HTML?

На этом уровне находятся люди, которые знают достаточно об HTML, чтобы изменить, добавить или удалить из документа пару-тройку тегов (на этом уровне всё называется тегами), которые они знают. Но особо сильного желания копаться в HTML у них никогда не возникает.

Разработчики второго уровня так же состоят из программистов, которые предпочитают безопасность Visual Studio или любой другой IDE, которую они используют. Они думают, что HTML — это слишком просто для них, и что их среда разработки достаточно продвинута, чтобы разобраться во все сама. Многие программисты второго уровня являются целевой аудиторией разработчиков CMS.

Уровень 3

Да, да. Я слышал об этих новых тэгах: ul, li и все такое. Но я отлично обхожусь своими любимыми table, img, br.

Многих веб-разработчиков старой школы, которые трудятся в индустрии с конца 90-х годов, можно найти на этом уровне. Вплоть до конца прошлого века эти люди писали HTML вручную, так что они знают все о вложенных таблицах и однопиксельных GIF-ах. С тех пор WYSIWYG-редакторы (такие как GoLive и Dreamweaver) улучшились до такой степени, что разработчики третьего уровня не видят никаких причин знать больше об HTML. Сейчас большая часть их работы, связанной с HTML, выполняется в дизайнерском режиме их редактора, поэтому они предпочли бы потратить свое время на изучение конкретного приложения, нежели вникать в то, что происходит за его кулисами.

Уровень 4

Слышь, а как можно сделать табличку с данными только div’ами и span’ами, не используя table?!

На этом уровне люди начинают сознательно использовать doctype-ы. На первом этапе это почти всегда переходный (transitional) doctype, чаще — XHTML 1.0 Transitional. Все таки XHTML является более поздней спецификацией чем HTML, так что наверное он лучше, правда? Люди на этом уровне являются также большими фанатами XHTML 1.1, наивно полагая, что более старшая версия подразумевает какие-то улучшения.

Услышав от кого-то, что использовать таблицы для разметки нельзя, многие программисты четвертого уровня используют div-ы для воссоздания таблицеподобных типов структуры. Так бывшие повара тег-супов становятся divоманами, которые денно и нощно производят тонны презентационной разметки с незамысловатами именами классов (red, blue, bigRedText и т.д.) и инлайновым CSS (атрибут style).

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

Уровень 5

Интересно, использование какого типа списка будет семантически более корректным в этом отрывке документа?

Большинство разработчиков, трудящихся в соответствие с канонам веб-стандартов, можно найти здесь. Эти люди, как правило, сначала думают о структуре и семантике и уже потом о представлении. На этом уровне обычно используются строгие (strict) doctype-ы, в целях поощрения разделения семантической и презентационной разметки. Будет ли это HTML версии 4.01 или XHTML версии 1.0, для многих не так уж и принципиально, хотя некоторые разработчики пятого уровня подвергают сомнению использование XHTML. На пятом уровне люди, как правило, склонны разводить бесконечные дискуссии о нюансах разметки. Они могут убить несколько часов, чтобы придумать имя для класса или реорганизовать HTML и CSS файлы.

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

Уровень 6

Я считаю спецификации HTML 4.01 и XHTML 2.0 семантически ограниченными. Поэтому я сейчас работаю над собственным языком разметки.

Эти люди являются мудрецами нашей отрасли. Они тратят много времени на то, что будет полезным лишь в будущем, а не прямо сейчас. Среднестатистический разработчик не сможет воспользоваться результатами значительной части их труда по крайней мере еще лет пять.

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

Читайте продолжение про CSS в следующей части.

10 способов проверить знания HTML/CSS

Если вы хотите совершенствовать свои навыки разработки, лучший путь к совершенству — практика. Предлагаем вашему вниманию ресурсы для проверки знаний в HTML/CSS.

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

Итак, предлагаем вам десять способов протестировать себя на знание HTML и CSS и стать более профессиональным веб-разработчиком.

Быть экспертом в теории — это замечательно, но вряд ли вы достигнете больших высот, если не умеете применять свои обширные знания на практике. Именно поэтому начать проект — лучший план действий для вас. В процессе разработки, например, собственного сайта, вы сможете отмечать прогресс и оценивать достижение своих целей.

Лучший способ проверить себя на прочность — принять участие в настоящих соревнованиях по программированию, например, в сообществе CodeWars. В форме игры вы соревнуетесь с другими реальными людьми, извлекая опыт из собственных ошибок. Но это имеет смысл только если вы играете честно.

Если соревнования — слишком сложный выбор для вас, особенно если вы совсем новичок, хорошим вариантом будет присоединиться к сообществу для тестирования и дальнейшего обучения. В процессе общения намного проще определять свои сильные и слабые стороны и работать над ними.

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

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

Ресурс содержит множество открытых для изучения проектов, что позволит вам понять, как они работают, и применить полученные знания в собственной практике. Время от времени с целью мотивации участников на сайте проводятся конкурсы, в которых можно помериться силами с другими программистами с возможностью занять высокие позиции в списке лидеров и выиграть призы.

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

В сети доступно необъятное множество опросников и паззловых игр, которые охватывают HTML, CSS и другие языки программирования. Как правило, они присутствуют на платных сайтах в качестве дополнения к обучающим курсам. Также вы можете поупражняться с более опытным наставником.

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

Самым простым способом объективно оценить навыки программирования является посещение сайта для тестирования. Тесты дают возможность поработать над разнообразными вопросами и хорошо потренироваться. Можно оценить свой уровень до и после прохождения какого-либо теста или курса тестов.

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

Clean Coders — это сайт, дающий такую возможность через профессиональные обучающие видео. Более того, эти видео весьма интересны, поэтому можете не беспокоиться о концентрации, вы втянетесь с первых минут.

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

10 вопросов, на которые должен ответить каждый, кто знает HTML

Скрытые возможности CSS: 10 полезных советов

Удобный тест по языку HTML с ответами

Вы решили пройти быстрый и удобный тест по HTML с ответами, но не знаете, куда можно обратиться за подобным? С эффективным решением данной проблемы поможет современный портал WebShake, созданный специально для всех желающих овладеть основами веб-разработки. Мы подготовили для вас удобную форму, с помощью которой вы сможете быстро, просто и совершенно бесплатно проверить свои знания.

Подробные сведения о тесте по HTML

Данный язык гипертекстовой разметки (HyperText Markup Language) считается общепринятым. Он оптимально подходит для незатруднительного создания интернет-страниц с различной структурой. Фактически, свободное владение данным языком позволяет разработчику:

создавать интернет-порталы;
прописывать структуру веб-сайтов;
разрабатывать всевозможные элементы и так далее.

Иными словами, специалисты, владеющие HTML, весьма востребованы в век активного развития интернета. Однако прежде чем начать разработку собственных веб-страниц, программисту необходимо освоить синтаксис языка и получить базовые знания по нему. Здесь пригодится онлайн тест по HTML.

Крайне важно регулярно проверять промежуточный итог, определяя собственный уровень знаний. Это же позволяет своевременно исправлять всевозможные ошибки в написании кода. Именно поэтому новичкам рекомендуется проходить тест по основам HTML не реже 1 раза в 2-3 недели.

Система, которую мы рады предложить вашему вниманию, разработана специально для быстрого и легкого обучения. Тест по языку HTML предоставляет целый ряд вопросов, однако после прохождения вам будут предоставлены все правильные ответы. Это поможет определить тематику, которую необходимо тщательно разучить и закрепить.

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

Насколько хорошо вы знаете CSS? (+ мини-тест) / Habr

Отличие между успешным использованием CSS и мучительными попытками справиться с ним, зачастую зависит от мелких деталей. На самом деле, в CSS очень много нюансов. Одна из наиболее часто встречающихся областей, где я часто замечаю такую борьбу — это стилизация макетов. Лично мне нравится изучать CSS-паттерны. Я заметил, что склонен использовать небольшое их количество для решения большинства проблем с макетом. Эта статья про те CSS-паттерны, которые я использую для преодоления проблем в вёрстке. Ситуации будут рассматриваться независимо от используемой CSS-методологии: будь то SMACSS, BEM или даже горячая тема CSS-in-JS, потому что все они сфокусированы на самих CSS-свойствах, а не на архитектуре, организации или стратегии.

Ради забавы, начнем с теста

Мы будем использовать разработанную мною платформу, которая называется Questionable.io и я использовал её для создания теста, к которому перейдем ниже. Не беспокойтесь, никакие персональные данные не собираются, результаты анонимны и это абсолютно бесплатно.

Цель тестирования в том, чтобы увидеть можете ли вы распознать специфичное поведение CSS и некоторые проблемы без предварительного ознакомления с материалом статьи. Я не собирался делать тестирование сложным, но нюансы CSS-стилизации могут быть довольно сложными. Помните, это тестирование просто ради забавы. Результаты теста не демонстрируют вашу крутость, но надеюсь, всё же будут полезными.

Тест состоит из 10 вопросов и должен занять не более 10 минут

От переводчика:
в конце статьи на Хабре добавлен опрос про количество набранных очков в тесте.

ПРОЙТИ ТЕСТ

Примечание: если не хотите тратить время, вот ссылка на вопросы с правильными ответами.

Прошли тест? Отлично! Давайте пройдемся по вопросам один за другим, чтобы получить лучшее представление о паттернах стилизации, которые затрагиваются в тесте.

Вопрос 1: Блочная модель

Изучение блочной модели должно быть приоритетным в списке любого FrontEnd-разработчика. Может статья «The CSS Box Model» немного и старовата, не стоит недооценивать её ценность и актуальность для современного CSS. Блочная модель является основой почти для каждого вопроса, относящегося к CSS-макетам.

Этот конкретный вопрос проверяет, как узнать ширину с учетом принципов блочной модели. Блок имеет явно заданную ширину через свойство width: 100px, но оказывается, что правила блочной модели по умолчанию, применяют свойства width к слою «content» данного блока. Итоговая ширина (насколько широким блок отрисовывается на странице) является суммой слоёв content, padding и border. Именно по этой причине ответ — 112px.

.box {
  width: 100px; /* Take this */
  height: 50px;
  padding: 5px; /* Plus this x2 for left and right */
  border: 1px solid red; /* Plus this x2 for left and right */
  background-color: red;
  /* = 112px of computed width */
}

Если вы сталкивались с ситуацией, в которой последняя колонка или вкладка в интерфейсе переносится вниз на следующую строку, хотя вы указали для всех width: 20%; и были уверены, что они поместятся в 100% родительского элемента, вероятно, это становилось проблемой. Пять колонок шириной по 20% помещаются в 100%, но если у них дополнительно задан padding и/или border, это увеличит ширину каждой, оставив недостаточно места в текущей строке для последней колонки.

Когда был представлен CSS3, появился новый инструмент под названием box-sizing. Он позволяет нам управлять тем, к какому слою блочной модели мы хотим применять свойство width. Например, мы можем указать box-sizing: border-box. Это означает, что мы хотим, чтобы любые правила width применялись к внешнему слою «border» вместо слоя «content». В вопросе из теста, если бы было применено свойство box-sizing: border-box, итоговая ширина блока составила 100px.

Для некоторых из вас это уже известный факт, но всё же будет неплохим напоминанием как для профессионалов, так и для новичков.

Существует целый ряд статей про блочную модель и про то, как использовать свойство box-sizing в качестве сброса, чтобы применить его сразу ко всему проекту. Box Sizing и Inheriting box-sizing Probably Slightly Better Best-Practice — две хорошие статьи с сайта CSS-Tricks, с которыми можно ознакомиться.

Вопрос 2: Границы элемента

Второй тестовый вопрос отчасти можно рассматривать как продолжение первого. Помните, одно дело прочитать: «Блочная модель имеет слои (content, padding, border) и все они влияют на итоговую ширину и высоту элемента», другое дело — уметь распознать проблемы блочной модели в реальной ситуации. Эта конкретная проблема является чем-то вроде классики среди тех, кто уже некоторое время работает с CSS. Она вытекает из того факта, что рамки займут определенное дополнительное пространство и оттолкнут окружающие элементы, поскольку являются частью блочной модели. Добавление рамок во время изменения состояния элемента, такого как :hover, будет значить, что блоки станут больше и тогда оттолкнут идущие следом блоки вниз. Это может раздражать:
Из всех возможных решений, указанных в тестовом вопросе, добавление border: 2px solid transparent к изначальному состоянию (без наведения курсора) является единственным возможным решением проблемы. box-sizing не решает эту проблему, потому что мы явно не задаём высоту. Если бы мы сделали это, рамка стала частью общей высоты элемента и сдвиг не происходил, но это не наш случай.

Существуют другие решения, которые мы не упомянули в вариантах ответа. Один из них — это добавление псевдо-рамки с помощью свойства box-shadow или использование outline вместо border. Каждый из них не будет приводить к смещению, так как не является слоем блочной модели. Вот другая статья на CSS-Tricks, где можно больше почитать про подобные решения.

Примечание:
Помните, что outline не поддерживает border-radius

Вопрос 3: Позиционирование — absolute против fixed

Помимо понимания того, когда использовать каждый из типов и как они отличаются в визуальном представлении, также очень важно знать правила того, как каждый из методов позиционирования привязывается к родительскому элементу с помощью свойств top, right, bottom или left.

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

1) Для абсолютных элементов. Содержащий блок — это ближайший предок, у которого позиционирование не static. Например, когда элемент абсолютно позиционирован, и содержит свойства top, right, bottom или left, они будет позиционироваться относительно любого родителя, который имеет позиционирование absolute, relative, fixed или sticky.
2) Для фиксированных элементов. Содержащий блок — это область просмотра, несмотря на наличие любых родительских элементов с позиционированием, отличным от static. Кроме того, поведение прокрутки отличается от абсолютно позиционированных элементов. Фиксированные элементы остаются «зафиксированными» в области просмотра, отсюда и название.

Многие разработчики думают, что абсолютно позиционированные элементы ищут лишь ближайший родительский элемент с относительным позиционированием position: relative. Это заблуждение стало распространённым просто потому, что position: relative чаще всего указывают в паре с position: absolute, чтобы сделать содержащий блок. Причина, по которой это часто используется в том, что относительное позиционирование родительского блока оставляет его в потоке, что зачастую является предпочтительным. Встречаются ситуации, когда родитель абсолютно позиционированного элемента сам является абсолютно позиционированным. Это совершенно нормальное явление. Если все родители статичные, тогда абсолютно позиционированный элемент будет прикрепляться к области просмотра — но так, чтобы прокручиваться вместе с областью просмотра.

Существует малоизвестное дополнение к правилам, указанным выше: в ситуациях, когда родительский элемент имеет свойство transform (помимо прочих) со значением, отличным от none, он становится содержащим блоком для абсолютно и фиксированно позиционированных элементов. Подтверждение этому можно увидеть в CodePen, где элемент с текстом «Notice!» — это фиксированный элемент, а родитель имеет свойство transform, но только когда на него наведен курсор мыши (в состоянии :hover)

Вопрос 4: Схлопывание margin родительского и дочерних элементов

Это одна из тех CSS мелочей, которая может доставить немало проблем, если вы не знаете, как она работает. Существует концепция, называемая схлопыванием margins и много людей знакомы с проявлением этого, называемым Схлопыванием margins смежных сестринских элементов. Тем не менее, существует и другая форма, называемая Схлопыванием margins родительского и первого/последнего дочернего элемента, которая менее известна. Ниже приведена демонстрация обоих случаев:
Каждый тег параграфа имеет верхний и нижний margin, равный 1em, что стилизуется браузером. Пока это самая легкая часть ситуации. Но почему промежуток между параграфами не 2em (сумма верхнего и нижнего)? Это называется схлопыванием margins смежных сестринских элементов. Margins перекрываются таким образом, что больший из двух margin будет составлять размер разрыва, таким образом, в данном случае разрыв будет равен 1em.

Однако происходит еще кое-что странное. Вы заметили, что верхний margin первого параграфа не создает промежуток между ним и голубым контейнером div? Вместо разрыва, он будто вкладывает margin в родительский div, как если бы div имел верхний margin. Это называется Схлопывание margins родительского и первого/последнего дочерних элементов. Этот тип схлопывания margins не будет происходить при определенных обстоятельствах, если родительскому элементу свойственно следующее:

Присутствует верхний/нижний padding больший нуля
Присутствует верхний/нижний border больший нуля
Задан Блочный контекст форматирования, который может быть создан с помощью overflow: hidden или overflow: auto
Задано свойство display: flow-root (плохая поддержка браузерами)

Когда я с удовольствием объясняю людям эту небольшую CSS-деталь и решаю это с помощью padding или border, ответ почти всегда: «А что насчет padding или border, равных 0?». Ну, это не работает, потому что значение должно быть целым положительным числом.

В предыдущем примере, padding размером в 1px позволяет нам переключиться между использованием схлопывание и предотвращением схлопывания margins родителя и дочернего элемента. Промежуток, который отображается между первым/последним параграфом и родительским элементом, это padding размером 1px, но теперь margin считается внутренней частью контейнера, поскольку слой padding создаёт барьер, предотвращающий схлопывание margins.

Что касается вопроса, я уверен, что вы можете увидеть, в чем проблема в этом интерфейсе:

У первого элемента с классом .comment (без класса .moderator) происходит схлопывание margins. Даже без просмотра кода мы можем увидеть, что у элемента с классом .moderator есть рамка, а у элемента без этого класса нет. В этом вопросе фактически было три ответа, которые считались правильными.Каждый из них на самом деле, уже применен в исходнике CodePen, они просто закомментированы.

Одна из причин, по которой этот тип схлопывания margins не так широко известен, как другие, заключается в том, что имеется множество ситуаций, при которых мы можем случайно избежать этого. Flexbox и Grid-элементы создают блочный контекст форматирования, поэтому при их использовании мы не сталкиваемся с этим типом схлопывания margins. Если бы интерфейс наших комментариев был реальным проектом, велики шансы, что со всех четырех сторон у нас были заданы paddings, чтобы оставить пространство вокруг, а это, в свою очередь, исправило для нас схлопывание margins.

Вопрос 5: Процент от чего?

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

В примере ниже мы можем видеть, что 50% принимают два разных значения в зависимости от контекста. Первый красный блок имеет свойство margin-left: 50%, а второй красный блок использует transform: translateX(50%).

Вопрос 6: Блочная модель наносит новый удар…

Только вы подумали, что мы закончили говорить о блочной модели…
Проблема проявляется из-за того, что мы используем width: 100% для футера и одновременно с этим добавляем padding. Ширина контейнера равняется 500px, что значит, что слой content футера (будучи 100%) также равняется 500px еще до того, как к этому размеру добавятся paddings.

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

Использовать свойство box-sizing для футера напрямую или через сброс, который упоминался раньше
Удалить у элемента свойство width и вместо него применить свойства left: 0 и right: 0. Это хороший пример одновременного использования свойств left и right. Такой подход позволит избежать проблем блочной модели, потому что свойство width будет использовать своё значение по умолчанию auto, чтобы заполнить любое доступное пространство между padding и borders, когда установлены left: 0 и right:0.

Примечание: одним из вариантов было удаление padding у футера. Технически это исправило бы проблему, потому что слой content был бы 100% и не имел padding или border, чтобы расшириться за пределы ширины контейнера. Но я думаю, это решение является неправильным подходом, потому что мы не должны менять наш интерфейс, чтобы приспособиться к проблемам блочной модели, которые и без этого легко исправляются.

Реальность для меня заключается в том, что у меня всегда выставлено свойство box-sizing: border-box, как часть моего общего сброса стилей. Если вы поступаете так же, скорее всего редко сталкиваетесь с этой проблемой. Но мне все равно нравится приём с одновременной установкой свойств left:0 и right:0, потому что, как показывается время, он более надежен (во всяком случае, судя по моему опыту), чем решение проблем блочной модели, возникающих из-за ширины 100%.

Вопрос 7: Центрирование абсолютных и фиксированных элементов

Теперь мы действительно начинаем объединять весь материал, описанный выше, с центрированием абсолютных и фиксированных элементов:
Поскольку мы уже охватили большую часть материала этого тестового вопроса, я просто обозначу, что горизонтальное и вертикальное центрирование может быть выполнено «олдскульным» методом через отрицательные margins, или более новым с помощью свойства transform. Также представляю вашему вниманию отличное CSS-Tricks руководство по центрированию элементов.

Примечание: некоторое время назад утверждали, что если мы знаем ширину и высоту блока, должны использовать отрицательные margins, потому что они работают более стабильно, чем новое свойство трансформации. В данный момент трансформация работает стабильно и я почти всегда использую именно это свойство, если только мне не нужно избежать преобразования блока в содержащий.

Вопрос 8: Центрирование элементов в нормальном потоке

Flexbox принес нам много удивительных инструментов для решения сложных задач с макетом. Перед его релизом сообщали, что вертикальное центрирование было одной из наиболее сложных функций, которые реализовывались в CSS. С приходом Flexbox вертикальное центрирование стало чем-то обыденным:

.parent { display: flex; }
.child { margin: auto; }

https://codepen.io/bradwestfall/pen/GPNmbM
Примечание: заметьте, что у flex-элементов margin: auto применяется к верху, низу, правой и левой стороне, чтобы центрировать элемент вертикально и горизонтально. Раньше вертикальное центрирование не работало для блочных элементов, поэтому достаточно распространена запись margin: 0 auto;

Вопрос 9: Расчеты с разными единицами измерения

Использование функции calc() прекрасно, когда нужно работать с двумя единицами измерения, которые мы не можем сложить самостоятельно или когда нам нужно сделать дроби более простыми для восприятия. Этот тестовый вопрос предлагает нам выяснить, каким будет результат выражения calc(100% + 1em), отталкиваясь от того факта, что ширина элемента div равна 100px. Это могло немного запутать, потому что на самом деле, не имеет значения, что ширина элемента div равняется 100px. Проценты всегда отталкиваются от ширины родителя, поэтому правильным ответом был: «100% содержащего (родительского) блока плюс 1em».

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

Особенность здесь в том, что мы хотим сделать выпадающее меню, которое может быть использовано вместе с вызывающими его элементами разного размера (в этом случае, два разных размера кнопок). Мы не знаем, какая будет высота элемента, вызывающего это меню, но мы знаем, что top: 100% разместит верхний край выпадающего меню у нижнего края вызывающей кнопки. Если каждое меню должно быть у нижнего края соответствующей кнопки, плюс 0.5em, этого можно добиться с помощью calc(100% + 0.5em). Конечно, мы также могли использовать top: 110%, но эти дополнительные 10% зависели бы от высоты вызывающей кнопки и контейнера.

Вопрос 10: Отрицательные margins

В отличие от положительных margins, которые отталкивают сестринские элементы, отрицательные margins притягивают их ближе друг к другу без смещения сестринских элементов. Этот финальный вопрос теста предлагает два решения, оба из которых технически приводят к устранению двойной рамки в нашей группе кнопок, но я настоятельно предпочитаю технику отрицательного margin, потому что удаление рамок сделало бы более сложным выполнение определенных приёмов, таких как эффект наведения мыши.
Получившийся эффект представляет собой «общую границу», которая отображается между кнопками. На самом деле, кнопки не могут иметь общую границу, поэтому нам нужно использовать приём с отрицательным margin, чтобы одна рамка перекрывала другую. Потом я использую z-index, чтобы устанавливать, какую рамку я хочу поместить выше другой, основываясь на состоянии наведения мыши. Обратите внимание, что z-index полезен здесь даже без использования абсолютного позиционирования, но пришлось задать position: relative. Если бы я использовал технику удаления левой рамки у второй кнопки, этот эффект было бы гораздо сложнее реализовать.

Всё это имеет смысл

Я хочу показать вам еще одно последнее демо, которое использует много приёмов, которые мы обсуждали до этого. Задача — создать плитки, которые расширяются до левого и правого края контейнера с учетом отступов. Под плитками я подразумеваю возможность иметь список блоков, которые переносятся на следующую строку, когда места по ширине не хватает. Наведите на плитки, чтобы увидеть результат:
Препятствием при выполнении этой задачи являются отступы. Без отступов было бы просто получить плитки, прилегающие к левому и правому краю контейнера. Проблема в том, что отступы будут созданы с помощью margins, а когда мы добавляем margins со всех сторон плитки, мы создаем две проблемы:

Наличие трёх плиток с шириной 33.33% в совокупности с margin не смогут поместиться в строке. Хотя box-sizing позволяет нам иметь padding и borders у элемента .tile и умещаться в 33.33%, это не поможет нам в случае с margins — а это значит, что рассчитываемая ширина трёх плиток будет больше 100%, что вынудит последнюю плитку перенестись на следующую строку.
Крайняя левая и правая плитки больше не будут прилегать к краю контейнера.

Первая проблема может быть решена с помощью calc((100% / 3) - 1em). Что значит 33.33% минус левый и правый margins каждой плитки. Схлопывание смежных сестринских элементов здесь происходить не будет, так как оно возможно только у верхнего и нижнего margin. В результате горизонтальное расстояние между двумя плитками — это сумма двух margins (1em). В этом случае схлопывание также не применится к верхним и нижним margins, потому что первая и последняя плитка технически не являются смежными, даже если визуально одна находится под другой.

С помощью приёма с calc(), три плитки могут поместиться в строке, но они все еще не прикасаются к краям контейнера. Для этого мы можем использовать отрицательные margins в размере, равном левому и правому margin каждой плитки. Зеленая точечная линия в примере — это контейнер, где мы применим отрицательные margins, чтобы нарисовать плитки, соответствующих краю окружающего содержимого. Мы можем видеть, как они прилегают к области padding родительского элемента. Это нормально, потому что отрицательные margins не отталкивают окружающие соседние элементы.

В итоге мы получаем плитки, которые имеют достаточные промежутки, которые расширяются от края до края так, что они выравниваются с соседними тегами абзаца вне плиток.

Существует много способов сделать плитки (и обычно они имеют свои преимущества и недостатки). Например, существует довольно элегантное решение с использованием CSS Grid, над которым рассуждал Хейдон Пикеринг. Данное решение реализуется с использованием техники, которая имитирует запросы к контейнерам (но с помощью магии Grid). В конечном счете, его решение с использованием Grid лучше, чем flexbox, которое я продемонстрировал, но имеет худшую поддержку браузерами.

Резюме

В начале я заявил, что склонен искать шаблоны при решении проблем. Эта статья не столько о продемонстрированных выше сценариях; она больше о наборе инструментов, которые можно использовать для решения этих и многих других проблем вёрстки, с которыми мы все можем столкнуться. Я надеюсь, что эти инструменты помогут вам.

Кстати, есть ряд отличных ресурсов, которые тщательно разбирают тему блочной модели. В первую очередь, статьи Рэйчел Эндрю и Джен Симмонс, с которыми определенно стоит ознакомиться.

Box Alignment Cheatsheet — отличный материал с визуальными элементами, которые подчеркивают различные свойства, которые влияют на то, как элементы выравниваются либо сами по себе, либо относительно других элементов
Jen Simmons Labs — множество полезных публикаций, демо и экспериментов с использованием современных методов разметки.

Тестирование по CSS — htmllab

Тест по CSS

Тестирование по CSS является продолжением теста по HTML. Он охватывает ряд модулей CSS по стандарту w3.org (на данный момент включены вопросы по 7 модулям — цвета CSS, CSS селекторы, CSS media queries, CSS фон, CSS блоки — боксы, CSS единицы измерения, рамки CSS ). Общее время теста не ограничено, в конце тестирования показываются неправильные ответы. Предлагается 10 заданий по CSS из общей базы с более чем сотней вопросов. Примечание: тест по CSS можно спокойно сдавать, изучив расширенный возможности HTML и CSS — в противном случае можно потерять время и огорчиться.

Тестирование по CSS

Удобней сдавать тест на странице Тестирование по CSS, но для тех, кто решил прочитать развернутый вариант новости, дублирую тест тут

Лимит времени: 0

Информация

Тест не привязан к каким-либо курсам и охватывает наиболее важные разделы CSS.

Вы уже проходили тест ранее. Вы не можете запустить его снова.

Тест загружается…

Вы должны войти или зарегистрироваться для того, чтобы начать тест.

Вы должны закончить следующие тесты, чтобы начать этот:

Правильных ответов: 0 из 10

Ваше время:

Время вышло

Вы набрали 0 из 0 баллов (0)

Средний результат
Ваш результат

Знание css html – HTML и CSS — зачем их нужно знать и почему познания в PHP и MySQL нужны, но в гораздо меньшем объеме