что сложнее html или css
Что сложнее html или css
Вы можете легко изучить HTML или CSS, так как их синтаксис довольно прост, даже если вы не знакомы с чем-то подобным раньше. Они не являются языками программирования, где соответственно разметкой и таблицей стилей. Конечно изучение синтаксиса языка не имеет никакого отношения к способности использовать его в реальных сценариях жизни, где необходим опыт.
Я бы сказал, что CSS сложнее, потому что он может быстро выйти из-под контроля, особенно в крупных проектах, где используются более сложные функции. В настоящее время он может стать очень ошеломляющим если вы не используете какой-либо автоматизированный инструмент «например для автоматического добавления префиксов поставщика» или предварительный процессор, как пример Sass.
HTML также может требовать, особенно при правильном использовании семантических элементов в вашей разметке. Я считаю, что простота обоих может сначала вводить в заблуждение, но в более крупных проектах вы можете увидеть послесловие, насколько легко все испортить!
Лучшие практики с HTML не совсем понятны, и там, где они используются, они редко используются. Для изучения этих вещей требуется время, чтобы просто изучить язык.
CSS для основных целей чрезвычайно прост. Для сложных конструкций это крайне непросто. И когда вы учитываете причуды браузера, это становится очень непростым.
С чисто теоретической точки зрения, они довольно просты. С точки зрения реального мира это не так.Страна: (RU)
15 ошибок или советов HTML и CSSОшибки и советы я написал по-своему опыту. Если найдутся ошибки типа «вредных советов», то буду рад услышать конструктивную критику. Пост предназначен для начинающих изучать HTML и CSS, но, возможно, специалистам тоже будет интересно ознакомиться с данным материалом. 1. W3C ValidatorРекомендуется проверять HTML и CSS сайта через сервис validator.w3.org. Данный сервис просканирует код и отобразит ошибки, например: 2. Вёрстка в формате UTF-8При вёрстке страницы, надо убедиться, что кодировка файла установлена в UTF-8 (без BOM). Каждый текстовый редактор устанавливает кодировку по-своему. Файл в формате UTF-8 позволяет использовать нестандартные символы (например, символы различных языков, знак валюты и другие). Также надо сообщить браузерам, что страница открывается в кодировке UTF-8. Это делается через тег ниже: 3. Одинаковые id у нескольких элементовЗначение атрибута id в HTML-коде не должно повторяться. 4. СпрайтыНесколько маленьких картинок рекомендуется соединять в один файл (такой файл называется спрайт). Это уменьшит количество запросов на сайт и улучшит скорость загрузки страницы. Сейчас также популярно вместо спрайтов использовать шрифты с иконками. Т.е. вместо букв выводятся иконки шестерёнки, смайлика и других иконок. В качестве примера можно привести иконки glyphicons, которые используются в Twitter Bootstrap. Преимущества шрифтов к спрайтам, это сохранение качества при изменении размера иконок и меньший размер. Но недостаток, нельзя использовать больше одного цвета в иконке. 5. Много селекторовНе рекомендуется использовать больше трёх селекторов, т.к. это влияет на производительность сайта. Если есть возможность, то выборку рекомендуется сокращать до одного селектора: 6. Стили в HTMLHTML предназначен для вывода информации (текст, картинки). Оформления контента (изменить размер, цвет, шрифт) происходит в CSS. 7. Неправильное названия классовЧтобы избегать подобных ситуаций, не рекомендуется применять классы для смены цвета, выравнивания текста, изменения регистра. Надо называть сами элементы (шапка, подвал, сообщение), и применять к нему свои стили. 8. Пиксели в дробных значенияхНекоторые браузеры позволяют указывать пиксели в дробных значениях, например «1.5px». Но это неправильно, т.к. пиксель это неделимая единица. Вместо «1.5px» лучше использовать «1.5em». 9. Использование классов вместо idРекомендуется делать выборку по классам вместо id, т.к. селекторы с id имеют больший вес, чем у классов, и их сложно будет переопределить. 10. МенюМеню должно быть оформлено как список. 11. Пропущенный alt у картинокВ тегах надо указывать атрибут alt (можно пустой). 12. Теги. В основном, в этом теге находится название страницы.13. ТранскрипцияНазвания всех элементов надо писать в английском переводе. Даже если не известно, как слово пишется по-английски, есть много бесплатных сервисов, которые могут перевести. Когда встречаются названия элементов транскрипцией, это выгладит непрофессионально. 14. ClearfixПро clearfix сложно написать в двух словах, но укажу момент, которые многие верстальщики, по моему мнению, делают ошибку. Что лучше использовать: css или html [закрыт]Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме. Вот заинтересовал вопрос: почему многие стараются сделать сайт на чистом CSS, без HTML таблиц? Есть ли смысл морочиться или сделать смесь (таблицы и стили)!? Мне кажется, так будет даже лучше, если стили не подгрузятся, страница будет читаемой. Объясните, пожалуйста, если ли принципиальная разница? 3 ответа 3Вопрос вообще от человека который ставит html и css на разные чаши весов. Это все используется совместно. Таблицы в разметке используются для вывода табличной информации, для другого существуют контейнеры, которые можно позиционировать по разному, в том числе только с помощью контейнеров(я про DIV) можно сделать дизайн подстраивающийся под любое разрешение экрана, чего никогда не добьешься при использовании таблиц. Сделать сайт на чистом css// на чистом CSS сайта сделать нель. можно. Но делают такое только полнейшие извращенцы(еще большие извращенцы, чем я). Какая-никакая HTML разметка крайне желательна. Все стили СТАРАЮТСЯ вынести в CSS, чтобы отделить стили от структуры: это позволит добавить новую страницу в едином стиле с предыдущими с минимальными усилиями. Таблицы стараются не использовать для взаиморасположения блоков потому что слишком тяжелая и очень негибкая структура.Очень непросто(извращенцы, привет!) заставить таблицу показать содержимое по-другому( td Я начал изучать html и css, но html я лучше усваиваю а css почти нет, это нормально?Простой 7 комментариев
То есть два жалких дня вы потратили на изучение чего-то с нуля, и уже вас это напрягло, уже лень и уже решили напрячь профи вам что-то пояснять в жизни? ИТ не для вас. Вот без обид, но это так. HTML дается легче, так как основное, что нужно знать о нем, это: C CSS дела обстоят сложнее, так как там очень много основных моментов, в отличии от HTML, о которых стоит знать. Упомяну некоторые из них: Глянул курс на codebra.ru, могу сказать, что максимальная информация по CSS из него составит 5-10% Мои рекомендации: Почему JavaScript пожирает HTML: примеры кодаВеб-разработка постоянно развивается. В последнее время стал популярным один тренд, который в основном противоречит общепринятому представлению о том, как нужно разрабатывать веб-приложения. Некоторые возлагают на него большие надежды, а другие испытывают разочарование. У каждого на это есть свои причины, которые в двух словах объяснить достаточно трудно. Код веб-страницы традиционно состоит из трех разделов, каждый из которых выполняет свои обязанности: HTML-код определяет структуру и семантику, CSS-код определяет внешний вид, а JavaScript-код определяет его поведение. В командах с участием дизайнеров, HTML / CSS разработчиков и JavaScript-разработчиков это разделение получается естественно: дизайнеры определяют визуальные элементы и пользовательский интерфейс, разработчики HTML и CSS размещают эти визуальные элементы на странице в браузере, а JavaScript-разработчики добавляют взаимодействие с пользователем, чтобы связать все вместе и «заставить это работать». Каждый может работать над своими задачами, не вмешиваясь в код остальных двух категорий разработчиков. Но все это справедливо для так называемого «старого стиля». В последние годы JavaScript-разработчики стали определять структуру страницы в JavaScript, а не в HTML (например, используя js-фреймворк React), что помогает упростить создание и сопровождение кода взаимодействия с пользователем. Без js-фреймворков разрабатывать современные веб-сайты гораздо сложнее. Конечно, когда вы говорите кому-то, что написанный им HTML-код необходимо разбить на части и смешать с JavaScript, с которым он знаком очень плохо, это (по понятным причинам) может быть воспринято в штыки. Как минимум собеседник спросит, зачем нам этого вообще надо, и как мы выиграем от этого. Как JavaScript-разработчику в межфункциональной команде, мне иногда задают этот вопрос, и часто мне трудно ответить на него. Все материалы, которые я нашел по этой теме, написаны для аудитории, которая уже знакома с JavaScript. А это не очень хорошо для тех, кто специализируется исключительно на HTML и CSS. Но паттерн HTML-in-JS (или что-то еще, что обеспечивает те же преимущества), вероятно, будет еще некоторое время востребован, поэтому я думаю, это важная вещь, которую должны понимать все, кто занимается веб-разработкой. В этой статье я приведу примеры кода для тех, кому интересно, но моя цель — объяснить этот подход так, чтобы его можно было понять и без них. Ликбез: HTML, CSS и JavaScriptЧтобы максимально расширить аудиторию этой статьи, я хочу кратко рассказать о том, какую роль эти языки играют в создании веб-страниц, и какое разделение между ними существовало изначально. Если вы все это знаете, можете пропустить этот раздел. HTML: для структуры и семантикиКод на HTML (HyperText Markup Language) задает структуру и семантику контента, который будет размещен на странице. Например, HTML-код этой статьи содержит текст, который вы сейчас читаете, и в соответствии с заданной структурой, этот текст размещен в отдельном абзаце, после заголовка и перед вставкой CodePen. Создадим, к примеру, простую веб-страницу со списком покупок: Мы можем сохранить этот код в файле, открыть его в веб-браузере, и браузер отобразит полученный результат. Как видите, код HTML в этом примере представляет собой страницу, которая содержит заголовок «Список покупок» (Shopping List (2 items)), текстовое поле ввода, кнопку «Добавить товар» (Add Item) и список из двух пунктов («Яйца» и «Масло»). Пользователь введет адрес в своем веб-браузере, затем браузер запросит этот HTML-код с сервера, загрузит его и отобразит. Если в списке уже есть элементы, сервер может прислать HTML с уже готовыми элементами, как в этом примере. Попробуйте набрать что-нибудь в поле ввода и нажать кнопку «Добавить элемент». Вы увидите, что ничего не происходит. Кнопка не связана ни с каким кодом, который мог бы изменить HTML, а HTML не может ничего изменить сам. Мы вернемся к этому через минуту. CSS: для изменения внешнего видаКод CSS (Cascading Style Sheets, Каскадные Таблицы Стилей) определяет внешний вид страницы. Например, CSS этой статьи задает шрифт, интервал и цвет текста, который вы читаете. Возможно, вы заметили, что наш пример списка покупок выглядит очень просто. HTML не позволяет задать такие вещи, как интервалы, размеры шрифтов и цвета. Поэтому мы и используем CSS. Мы могли бы добавить CSS-код для этой страницы, чтобы немного украсить ее: Как видите, этот CSS-код изменил размер и толщину символов текста, а также цвет фона. Разработчик может по аналогии написать правила для собственного стиля, и они будут последовательно применяться к любой структуре HTML: если мы добавим на эту страницу элементы section, button или ul, для них будут действовать те же изменения шрифта. JavaScript: для реализации поведенияКод JavaScript определяет поведение интерактивных, или динамических, элементов на странице. Например, CodePen написан с использованием JavaScript. Вот так раньше работали все веб-приложения: каждый раз, когда пользователь взаимодействовал с веб-страницей, он как будто закрывал свой веб-браузер и снова открывал его. Это не имеет большого значения для простого учебного примера, но для большой сложной страницы, загрузка которой может занять некоторое время, такой подход не эффективен ни для браузера, ни для сервера. Если мы хотим что-то менять на странице без полной перезагрузки этой страницы, нам нужно использовать JavaScript: Теперь, когда мы набираем текст в поле ввода и нажимаем кнопку Add Item, наш новый элемент добавляется в список, а количество элементов в верхней части обновляется! В реальном приложении мы также добавили бы некоторый код для отправки нового элемента на сервер в фоновом режиме, чтобы он отображался при следующей загрузке страницы. Отделение JavaScript от HTML и CSS оправданно даже в этом простом примере. Более сложные взаимодействия работают так: HTML загружается и отображается, а впоследствии запускается JavaScript, чтобы добавить что-то к нему и изменить его. Однако по мере роста сложности веб-приложения, нам нужно внимательнее следить за тем, что, где и когда меняет наш JavaScript-код. Если бы мы продолжали развивать это приложение со списком покупок, то, возможно, добавили бы кнопки для редактирования или удаления элементов из списка. Допустим, мы напишем JavaScript-код для кнопки, которая удаляет элемент, но забудем добавить код, который обновляет информацию об общем количестве элементов в верхней части страницы. Внезапно у нас возникает ошибка: после того, как пользователь удалит элемент, указанное общее количество на странице не будет соответствовать списку! Как только мы заметили ошибку, мы исправили ее, добавив ту же строку totalText.innerHTML из нашего кода для Add Item в код для Remove Item. Теперь у нас одинаковый код, который дублируется в нескольких местах. Позже, скажем, мы захотим изменить этот код так, чтобы вместо «(2 items)» вверху страницы он выводил «Items: 2». Мы должны убедиться, что не забудем обновить этот код во всех трех местах: в HTML, в JavaScript-коде для кнопки Add Item и в JavaScript-коде для кнопки Remove Item. Если мы этого не сделаем, у нас будет другая ошибка, из-за которой этот текст будет резко меняться после взаимодействия с пользователем. Уже в этом простом примере мы видим, как легко запутаться в коде. Конечно. существуют подходы и практики, позволяющие упорядочить JavaScript-код, чтобы облегчить решение этой проблемы. Однако, по мере того, как все будет становиться сложнее, нам придется продолжать реструктуризацию и постоянно переписывать проект, чтобы его можно было спокойно развивать и сопровождать. Пока HTML и JavaScript хранятся отдельно, может потребоваться много усилий, чтобы обеспечить синхронизацию между ними. Это одна из причин, по которой стали популярны новые JavaScript-фреймворки, такие как React: они предназначены для обеспечения более формализованных и эффективных взаимоотношений между HTML и JavaScript. Чтобы понять, как это работает, нам сначала нужно немного углубиться в компьютерную науку. Императивное vs декларативное программированиеКлючевая вещь, которую необходимо понять, — это разница в мышлении. Большинство языков программирования позволяют следовать только одной парадигме, хотя некоторые из них поддерживают сразу две. Важно понимать обе парадигмы, чтобы оценить по достоинству основное преимущество HTML-in-JS с точки зрения разработчика JavaScript. HTML — декларативный языкЗабудьте о JavaScript на мгновение. Вот важный факт: HTML является декларативным языком. В HTML-файле вы можете объявить что-то вроде: Когда веб-браузер прочитает этот HTML-код, он самостоятельно определит необходимые шаги и выполнит их: JavaScript — императивный языкМы уже рассмотрели простой пример императивного JavaScript в приведенном выше примере списка покупок, и я описал, как сложность функций приложения влияет на усилия, необходимые для их реализации, и на вероятность появления ошибок в этой реализации. Теперь давайте рассмотрим немного более сложную задачу и посмотрим, как ее можно упростить с помощью декларативного подхода. Представьте себе веб-страницу, которая содержит следующее: Головная боль как она естьУ нас тут большая проблема на самом деле: нет сущности, которая бы содержала полную информацию о состоянии нашего приложения (в данном случае это ответ на вопрос «какие флажки помечены?») и несла бы ответственность за обновление этой информации. Флажки, конечно же знают, помечены ли они, но об этом также должны знать CSS-код для рядов таблицы, текст и каждая кнопка. Пять копий этой информации хранятся отдельно по всему HTML, и когда она изменяется в любом из этих мест, JavaScript-разработчик должен отловить это и написать императивный код для синхронизации с изменениями в других местах. И это все еще простой пример одного небольшого компонента страницы. Если даже этот набор инструкций выглядит как головная боль, представьте, насколько сложным и хрупким становится более крупное веб-приложение, когда вам нужно реализовать все это на императивном JavaScript. Для многих сложных современных веб-приложений такое решение не масштабируется от слова «совсем». Ищем источник правдыТакие инструменты, как React, позволяют декларативно использовать JavaScript. Так же как HTML является декларативной абстракцией над инструкциями по отображению в веб-браузере, так и React является декларативной абстракцией над JavaScript. Помните, как HTML позволяет нам сосредоточиться на структуре страницы, а не на деталях реализации, и как браузер отображает эту структуру? Точно так же, когда мы используем React, мы можем сосредоточиться на структуре, определив ее на основе данных, хранящихся в одном месте. Такой процесс называется односторонним связыванием, а место хранения данных о состоянии приложения называется «единым источником правды». Когда источник правды изменится, React автоматически обновит для нас структуру страницы. Он позаботится об обязательных шагах за кулисами, как это делает веб-браузер для HTML. Хотя в качестве примера здесь используется React, этот подход работает и для других фреймворков, например Vue. Давайте вернемся к нашему списку флажков из примера выше. В этом случае «правда», которую мы хотим знать, довольно лаконична: какие флажки помечены? Другие детали (например, текст, цвет строк, какие кнопки включены) — это уже информация, полученная на основе источника правды. И почему же они должны иметь свою собственную копию этой информации? Они должны просто использовать единый источник правды только для чтения, и все элементы страницы должны «просто знать», какие флажки помечены, и вести себя соответственно. Вы можете сказать, что ряды таблицы, текст и кнопки должны иметь возможность автоматически реагировать на флажок в зависимости от того, помечен он или не помечен (“видите, что там происходит?”) Скажи мне, чего ты хочешь (чего ты хочешь на самом деле)Чтобы реализовать эту страницу с помощью React, мы можем заменить список несколькими простыми описаниями фактов: Перепишем наш пример на React: JSX выглядит своеобразно. Когда я впервые столкнулся с этим, мне показалось, что так делать просто нельзя. Моей первоначальной реакцией было: «Чтоааа? HTML не может находится внутри JavaScript-кода!». И я был не один такой. Тем не менее, это не HTML, а JavaScript, одетый как HTML. На самом деле, это мощное решение. Помните те 20 императивных инструкций выше? Теперь у нас их три. Остальные (внутренние) императивные инструкции React сам выполняет для нас за кулисами — каждый раз, когда изменяется checkboxValues. С этим кодом теперь не может произойти ситуация, когда текст или цвет строки не соответствует флажкам, или когда кнопка включена, хотя она должна быть отключена. Существует целая категория ошибок, которые сейчас просто не могут возникнуть в нашем веб-приложении. Вся работа выполняется на основе единого источника правды, и мы, разработчики, можем писать меньше кода и лучше спать по ночам. Ну, JavaScript-разработчики, по крайней мере… JavaScript победил HTML: взял изморомПо мере усложнения веб-приложений поддержание классического разделения задач между HTML и JavaScript становится все более болезненным. Первоначально HTML был разработан для статических веб-страниц. Чтобы добавить туда более сложные интерактивные функции, необходимо реализовать на императивном JavaScript соответствующую логику, которая с каждой строчкой кода становится все более запутанной и хрупкой. Преимущества современного подхода: предсказуемость, возможность повторного использования и комбинированияВозможность использовать единый источник правды является наиболее важным преимуществом этой модели, но у нее есть и другие преимущества. Определение элементов нашей страницы в коде JavaScript означает, что мы можем повторно использовать компоненты (отдельные блоки веб-страницы), не позволяя нам копировать и вставлять один и тот же HTML-код в нескольких местах. Если нам нужно изменить компонент, достаточно изменить его код только в одном месте. При этом изменения произойдут во всех копиях компонента (внутри одного или даже во многих веб-приложениях, если мы применяем в них повторно используемые компоненты). Мы можем взять простые компоненты и составить их вместе, как кубики LEGO, создавая более сложные и полезные компоненты, не делая их логику слишком запутанной. А если мы используем компоненты, созданные другими разработчиками, мы можем легко накатить обновления или баг-фиксы без необходимости переписывать наш код. Тот же JavaScript, только в профильЭти преимущества имеют свою обратную сторону. Есть веские причины, по которым люди ценят разделение HTML и JavaScript. Как я уже упоминал ранее, отказ от обычных HTML-файлов усложняет рабочий процесс для того, кто раньше не работал с JavaScript. Тот, кто ранее мог самостоятельно вносить изменения в веб-приложение, теперь должен приобрести дополнительные сложные навыки, чтобы сохранить свою автономию, или даже место в команде. Также есть и технические недостатки. Например, некоторые инструменты, такие как линтеры и парсеры, принимают на вход только обычный HTML, а работать вместо них со сторонними плагинами JavaScript может оказаться сложнее. Кроме того, JavaScript не самый лучший язык, но это единый стандарт, принятый для веб-браузеров. Новые инструменты и функции делают его лучше, но в нем все же есть некоторые подводные камни, о которых вам необходимо узнать, прежде чем вы будете работать с ним. Другая потенциальная проблема: когда семантическая структура страницы разбивается на абстрактные компоненты, разработчик может перестать думать о том, какие элементы HTML будут сгенерированы в результате. Специфические HTML-теги, такие как section и aside, имеют свою семантику, которая теряется при использовании тегов общего назначения, таких как div и span — даже если они визуально выглядят одинаково на странице. Это особенно важно для обеспечения доступности веб-приложения для разных категорий пользователей. Например, это повлияет на поведение программы чтения с экрана для пользователей с нарушениями зрения. Возможно, это не самые интересные для разработчика задачи, но JavaScript-разработчики всегда должны помнить, что сохранение семантики HTML в данном случае является наиболее важной задачей. Осознанная необходимость vs неосознанный трендВ последнее время использование фреймворков в каждом проекте стало трендом. Некоторые считают, что разделение HTML и JavaScript устарело, но это не так. Для простого статического веб-сайта, который не требует сложного взаимодействия с пользователем, это как раз подойдет. Более ярые поклонники React могут не согласиться со мной здесь, но если все, что делает ваш JavaScript, — это создание неинтерактивной веб-страницы, вам не следует использовать его. JavaScript загружается не так быстро, как обычный HTML. Поэтому, если вы не ставите задачу получить новый опыт разработки или повысить надежность кода, JavaScript тут принесет больше вреда, чем пользы. Кроме того, нет никакой необходимости писать весь свой веб-сайт на React. Или Vue! Или что там еще есть… Многие люди не знают этого, потому что все учебники в основном показывают, как использовать React для разработки сайта с нуля. Если у вас есть только один маленький сложный виджет на простом веб-сайте, вы можете использовать React для одного компонента. Вам не всегда нужно беспокоиться о webpack, Redux, Gatsby или еще о чем-то, что кто-то там рекомендует как «лучшие практики». Но если приложение достаточно сложное, использование современного декларативного подхода абсолютно стоит того. Является ли React наилучшим решением? Нет. У него уже сейчас есть сильные конкуренты. А потом появятся еще и еще… Но декларативное программирование никуда не денется, и в каком-нибудь новом фреймворке, вероятно, этот подход будет переосмыслен и реализован еще лучше.
|