Длиннющие имена файлов, пустые строки, абзацы табуляцией, заголовки по центру, за-span-енный текст, цвет и размер шрифта, а также другие излишние атрибуты качественной ХТМЛ разметки текста.
Не хватит никакого здравия чтобы приспособиться к этому глубоко больному обществу. Реплика из Д/Ф Дух времени.
Недостаточно просто иметь в наличии руки/ноги/голову - ими ещё нужно уметь правильно пользоваться! Довольно часто приходится доказывать казалось бы вполне очевидные, но почему-то не всем понятные моменты. Например (из инструкций по эксплуатации):
- Не останавливать работящую пилу руками или гениталиями.
- Запрещено доверять установку лицам в состоянии алкогольного опьянения и беременным женщинам. Запрещено есть антенну. Запрещено бросать антенну в супруга/супругу.
- Из этикетки на штанах: Молния может защемить вам пенис. Осторожнее!
- На одеяле (made in Taiwan): Не используйте как защиту от торнадо!
- Осторожно - горячо! Избегайте проливания на штаны.
- На фене фирмы Sears: Не используйте во сне!
- ...ну, и всё в такое прочее.
Согласитесь, забавно? Но, раз такие рекомендации заносят в инструкции по применению, то очевидно такие случаи уже бывали!
К написанию сего мануала сподвигли неоднократные вопросы наших многоуважаемых Клиентов о том, - как, зачем да почему у них на выходе всегда получается ХТМЛ говно-код при оформлении статей/постов/материалов. Кроме того, возможно данный материал ещё кому-то в этом мире будет полезен.
Нижеследующее довольно проблематично вновь и вновь перепечатывать ручками в электронной переписке или содрогая воздух объяснять по испорченным телефонам, а это аж никак не объектно-ориентированный подход к вопросу!
В данном материале попробуем собрать основные рекомендации для более-менее качественной ХТМЛ разметки текста.
Чем опасен говно-код
Ответ очевиден! Частый просмотр страниц сотканных из говно-кода - это:
- излишняя трата системных ресурсов на рендеринг (отображение/отрисовку) страницы, в т.ч. ресурсов ЦП;
- ускоренное пересыхание термопасты на процессорах из-за чего ПК может внезапно отключаться для защиты ЦП от повреждения, или ЦП может даже полностью выгореть образовав дырку в плате если в БИОС-е нет защиты или она отключена;
- повышенное потребление электроэнергии, пыхтят-дымят атомные электростанции, усиливается глобальное потепление, ухудшается общая экологическая обстановка;
- часто некорректное и/или непредсказуемое отображение веб-страницы.
На бортовой панели рабочего стола всегда привык видеть показания датчиков оборотов вентилятора и температуры процессора, так отмечу, что для отрисовки одной говно-страницы на каком-то из говно-маркетплейсов:
- температура ЦП с 58С поднимается до 75С, но кому до этого какое дело;
- вентилятор ЦП повышает обороты чтобы снизить температуру - это слышно по звуку, так видно и по датчикам;
- вольтаж на вентиляторе также повышается.
Не нужно никаких программы для стресс-тестирования процессора типа AIDA 64/OCCT/IntelBurnTest/PRIME 95, достаточно вывести показания датчиков на панель и посетить какой-то говно-маркеплейс.
На некоторых говно-сайтах страницы криво-косо отображаются или даже вовсе не отображаются в некоторых версиях браузеров.
Очень часто попадают говно-сайты, просматривая страницы которых замечено повышенная нагрузка на ЦП, при этом вся реклама заблокирована и разрешены только скрипты с посещённого домена - это наталкивает на мысль, что на страницах сайта то ли скрытый майнинг криптовалюты включается, то ли ещё какое-то ГАВнище чего-то там туда-сюда юлдусит.
Повышенной нагрузкой на ЦП также отмечены:
- цифровая проститутка София (обычно в правом нижнем углу экрана тусуется), которая неустанно тебе машет и подмигивает - манит значит;
- анимированная труба обратной связи/чата;
- падающие снежинки на заднем фоне, от которых аж ноги мёрзнут;
- прочие на хрен не нужные понты для приезжих грызущие твой ЦП.
Всё то ГАВнище в комплексе и убивает наши нервы/время/деньги/гаджеты, а в конечном итоге окружающую среду и всё живое на ней. Поэтому, говнокод === смерть!
Базовые фичи TinyMCE
Будем использовать визуальный ХТМЛ редактор TinyMCE. Без ознакомления с базовыми его функциями, следовать дальнейшим рекомендациям будет затруднительно.
Шаблоны
Шаблоны TinyMCE прилично экономят время при создании новых материалов, особенно если сайт мультиязычный и для каждой языковой версии есть некоторые отличия в структуре.
Нажав на иконку Вставить шаблон появится окно со списком шаблонов и предварительным просмотром.
Выбираем из списка подходящий шаблон, например post-ru.txt, и нажимаем Сохранить.
Шаблоны TinyMCE размещены по адресу:
- Joomla 3.x: /media/editors/tinymce/templates/ - с расширением *.html, например post-ru.html;
- Joomla 4.x: /templates/mytemplate/html/tinymce/ - с расширением *.txt, например post-ru.txt.
Показывать блоки
Следующая особо важная фича - это Показывать блоки.
При редактировании материала мы будем наблюдать основные (родительские) блоки обрамлённые пунктиром, а также дочерние (вложенные) блоки такие, как выделение текста жирным например.
Если кликнуть в любом месте жирного текста, то в нижней части редактора будет отображено имя тега STRONG и блока P в котором он находится: P >> STRONG
Имена блоков и тегов в нижней части редактора являются кликабельными.
Кликнув по имени тега STRONG будет выделен весь текст в этом теге, а повторно кликнув в редакторе на символ В выделение текста жирным будет отменено.
Аналогично можно поступать с блоком параграфа P, превратив его в заголовок H2 или блок DIV.
Вставить как текст
Основной проблемой загаженности текста ХТМЛ разметкой и лишними стилями является то, что тексты принято не писать самостоятельно, а копипиздить их с других сайтов.
Когда происходит копировать/вставить, то скопированный с другого сайта текст вставляется в редактор вместе с ХТМЛ разметкой и стилями того сайта с которого скопирован!
Для отмены такого поведения нужно в редакторе активировать фичу Вставить как текст (значок буквы Т на фоне планшета).
Однако, в режиме Вставить как текст в самом редакторе нельзя будет клонировать блоки их копированием. Например, чтобы скопировать блок DIV и всё его содержимое в другое место материала, нужно отменить/деактивировать фичу Вставить как текст и активировать её повторно при необходимости вставки текста.
ПОДСКАЗКА!
Если вставить текст например из 3-х строк в режиме Вставить как текст, то каждая строка будет оформлена в свой отдельный тег параграфа <P> (зависит от настроек редактора), в противном случае все три строки текста будут вставлены в один общий тег параграфа <P> и между собой разделены тегами <BR>
Исходный код
Иногда нажимайте иконку Исходный код (Source code+) проверяйте там наличие в тегах атрибутов style="" типа <H2 style="text-align: center;">ЗАГОЛОВОК</H2> <P style="font-size: 10px">ПАРАГРАФ</P>, и других признаков говно-кода.
Выключить редактор
Альтернативным вариантом плагину Исходный код является кнопка Выключить редактор.
Хорошей привычкой будет перечитывание исходного кода после подготовки его в визуальном редакторе.
Каким бы не был любой визуальный ХТМЛ редактор, он не обеспечит всех потребностей профессионального верстальщика.
Вставка изображения
Вставка изображения в редактор TinyMCE - это тема, про которую можно писать книги и снимать фильмы ужасов.
Сценарий ужасов здесь зависит ещё не столько от конечного пользователя, как от разработчиков TinyMCE и разработчиков движка в который интегрируется/встраивается редактор.
Первое место в этом кошмаре занимает отсутствие возможности гибкого конфигурирования модулей TinyMCE через панель администратора без необходимости перепила файлов контроллеров самого плагина движка, - это к разработчикам движка.
На втором месте иногда почти недокументированное поведение (по-умолчанию) плагинов TinyMCE, а как его изменить догадывайся сам - это к разработчикам TinyMCE.
Ну, а юзер.., - ни в чём не виноват.
Ленивая загрузка изображения и мутный атрибут data-path
В Joomla 4.x появилася убогая и навящивая реализация давно вездесущей фичи lazy loading. Пользователи движка Joomla 4.x заметили появление странных атрибутов и параметров, которые автоматически и навящиво стали добавляться к тегу изображения, например:
Strange article image url - Joomla! Forum - community, help and support
I see the same. All articles created in latest Joomla 4.0.3 has such additional "#joomlaImage://local-images/...?width=...&height=..." in intro images URL.
Who can describe this implementation? Or this is a bug?
Это фича или бага?
- спрашивают участники форума.
Одним из таких обязательных (по мнению говнокодеров joomla) стал неубиваемый атрибут data-path. Участник форума by ceford » Mon Dec 06, 2021 11:38 am отметил, что в data-path указывается путь с которым будет работать отложенная загрузка изображений и дал ссылку на пост описания lazy loading.
В том посте для отложенной загрузки изображений предлагается использовать атрибут с именем data-src, а не data-path, как то происходит в случае с Joomla 4.x.
Тобишь, имя атрибута data-src или data-path для lazy loading может быть каким угодно в зависимости от фантазий и хотелок говнокодера (например data-url or data-uri), а также требует поддержки/включения JavaScript в браузере.
Global attributes - HTML: HyperText Markup Language | MDN
...
data-*
Forms a class of attributes, called custom data attributes, that allow proprietary information to be exchanged between the HTML and its DOM representation that may be used by scripts. All such custom data are available via the HTMLElement interface of the element the attribute is set on. The HTMLElement.dataset property gives access to them.
Атрибут data-path (реализация разработчиков joomla) вместе с атрибутом loading (реализация браузеров) добавляется к тегу изображения при его вставке через стандартный Контент CMS -> Медиа медиа-менеджер из Joomla 4.x, где в Дополнительные параметры по-умолчанию включена Ленивая загрузка изображения
В итоге получится такой говнокод: <img src="https://static.itmag.pro/images/post/2023/myimg.webp" loading="lazy" data-path="local-images:/post/2023/myimg.webp" />
ОБРАТИТЕ ВНИМАНИЕ!
В теге <img ... /> отсутствует обязательный атрибут alt="", без которого код не пройдёт АГС (АнтиГовноСайт) валидацию и не будет соответствовать ХТМЛ стандарту!
Обязательный атрибут alt="" нужно будет после вставки добавлять, кликнув на изображении, а потом по иконке Вставить/редактировать изображение, в поле Alternative description.
Если при вставке изображения снять галку с Ленивая загрузка изображения, то атрибут loading="lazy" исчезнет, но data-path="" на кой-то хрен останется.
Управление этими атрибутами через стандартный плагин TinyMCE редактора Вставить/редактировать изображение - НЕВОЗМОЖНО!
Как ранее упоминалось, отложенная загрузка по атрибуту loading реализована в браузерах (начиная с неких версий):
- Lazy loading - Web performance | MDN
- HTMLImageElement: loading property - Web APIs | MDN
- HTML img loading Attribute
Может возникнуть закономерный вопрос: А на кой хрен тогда дополнительная реализация Lazy loading по атрибутам data-src / data-path!? Неужели нельзя взять путь к изображению из всегда имеющегося по-умолчанию атрибута src!? Нафига бляха такие сложности!?
В сухом остатке:
- loading="" - велосипед уже придуман;
data-path="" - кастомный вариант велосипеда вероятно создавался для браузеров без поддержки атрибута loading;
ngx_pagespeed - модуль для Nginx сервера с реализацией Lazy loading;
mod_pagespeed - модуль для Apache сервера с реализацией Lazy loading.
Приходим к выводу, что:
- атрибуты loading="" и в особенности data-path="" нужно нахрен удалять из ХТМЛ кода;
- прямая вставка в ХТМЛ код изображений атрибутов loading="" и в особенности data-path="" могут существенно увеличить в объёме размер БД сайта;
- Lazy loading может быть применено с помощью плагина или модулей сервера;
- необходимость поддержки/включения JavaScript в браузере лишает смысла применение Lazy loading для браузеров без JavaScript;
- технология призванная экономить, по факту создаёт новые нагрузки и головные боли, и лишь за редким исключением польза может превышать ущерб, например при листинге страниц галерей с изображениями;
- за автоматическое добавление data-path="" в ХМТЛ код без ведома автора, разработчикам Joomla 4.x нужно ручки повыдёргивать.
Что делать?
Пока ещё никто не жаловался!
Ты чувак можешь стать первым!Встань и выйди из ряда вон, сядь на электрический стул Электрон
, и - начни ХолиВар на https://github.com/joomla/joomla-cms/issues;- после закачки не вставлять изображения через Контент CMS -> Медиа медиа-менеджер, а при наведении курсора на изображение вызывать меню (троеточие в правом вернем углу изображения) Действия с элементом и там выбрав пункт Получить ссылку, которую потом вставлять либо через Вставиьт/редактировать изображение либо через Исходный код;
- после закачки вставлять изображения через Контент CMS -> Медиа медиа-менеджер, а потом через Исходный код удалять навящивые атрибуты loading="" и data-path="" в особенности;
- забить на всё и пусть ком говнокода растёт и множится.
Размер изображений
Стандарт рекомендует к изображениям добавлять атрибуты width="" и height="" определяющие размер, что избавляет ЦП от излишней работы по вычислению и позиционированию изображения при отрисовке веб-страницы в браузере, - это на все 100% верно!
Однако, при Вставить/редактировать изображение через стандартный модуль TinyMCE редактора, размер изображения вычисляется и width="1000" height="1000" безальтернативно добавляется к тегу изображения.
Хотя, размер изображения может быть установлен в ЦСС-классе, например:
<p><img class="float-start img-thumbnail" title="" src="https://static.itmag.pro/images/myimg.jpg" alt="" /> Вступительный текст</p> <hr id="system-readmore" /> <p>Место для основного текста, продолжение вступительного</p>
И, если фактические размеры images/myimg.jpg равны 1000х1000, а размеры установленные в ЦСС-классе img-thumbnail равны 250х250, то при Вставить/редактировать изображение вычисляя размеры TinyMCE предпочтёт размеры из img-thumbnail равные 250х250.
Без ЦСС-класса img-thumbnail размеры TinyMCE возьмёт из images/myimg.jpg равные 1000х1000.
Так или иначе, при Вставить/редактировать изображение через стандартный модуль TinyMCE, размеры width="" height="" будут по-умолчанию автоматически и принудительно добавлены.
Нам же нужен максимально чистый код тега <img class="" title="" src="https://static.itmag.pro/" alt="" />, как в примере выше, без width="" height="", loading="" и в особенности data-path="".
Кто виноват и что делать?
Кто виноват, что отсутствует возможность гибкого конфигурирования модулей/плагинов TinyMCE через панель администратора без необходимости перепила файлов контроллеров самого плагина движка, - ответ тут думаю очевиден!
Что делать?
Пока ещё никто не жаловался!
Ты чувак можешь стать первым!Встань и выйди из ряда вон, сядь на электрический стул Электрон
, и - начни ХолиВар на https://github.com/joomla/joomla-cms/issues, чтобы они все настройки TinyMCE неподконтрольные через админпанель вынесли в отдельный (XML или PHP/JS/TXT) файл с возможностью его переопределения в каталоге шаблона;- допиливать/перепиливать сам файл плагина движка (joomla3: /plugins/editors/tinymce/tinymce.php), в который вносить дополнительную конфигурацию TinyMCE, но эти изменения будут утеряны при каждом следующем обновлении движка;
- image_class_list - array(), массив с именами классов добавляемых к изображению;
- image_dimensions - false, запрещает автоматическое добавление размеров width="" height="";
- сделать отдельный шаблон TinyMCE для изображений с заранее причёсанным кодом, потом из Контент CMS -> Медиа медиа-менеджера копировать УРЛ к изображению, после чего ручками прописывать его в атрибут src через Исходный код;
- забить на всё и пусть ком говнокода растёт и множится.
Альтернативное описание
Добавил атрибут альтернативного описания alt= свой для каждого языка. Это ..здееец. Я так понимаю тут запросы нужно для поисковых систем писать по поисковым запросам? И транслитом. Без черточек но с пробелами. Все с маленькой буквы. Или ХЗ с какой надо?
НЕ нужно никаких запросов для поисковых систем в alt="" выдумывать! Альтернативное описание изображения должно информативно, а главное максимально кратко, описывать само изображение и не более того - без лжи и спама.
Атрибут альтернативного описания alt="" может содержать текст на любом языке с чёрточками/подчёркиванием/точками/пробелами - можно вставить имя изображения, если оно информативное и соответствует контексту самого изображения.
<img>: The Image Embed element - HTML: HyperText Markup Language | MDN
https://developer.mozilla.org/ru/docs/Web/HTML/Element/img#attr-altalt - Этим атрибутом задаётся альтернативное текстовое описание изображения.
Примечание: Браузеры не всегда отображают изображение на которое ссылается элемент. Это относится к неграфическим браузерам (включая те, которые используются людьми с нарушениями зрения), если пользователь решает не отображать изображения, или если браузер не может отобразить изображение, потому что оно имеет неверный или неподдерживаемый тип. В этих случаях браузер может заменить изображение текстом записанным в атрибуте alt элемента. По этим и другим причинам вы должны по возможности предоставлять полезное описание в атрибуте alt. Примечание: Установка этого атрибута в значение пустой строки (alt="") указывает, что это изображение не является ключевой частью контента (декоративное), и что невизуальные браузеры могут пропустить его при рендеринге (en-US).
https://developer.mozilla.org/en-US/docs/Glossary/Rendering_engine
Спецсимволы в атрибутах
Спецсимволы желательно не должны использоваться в атрибутах, включая alt="" и title="", а также именах файлов!
Особенно это касается таких спецсимволов как:
'одинарные кавычки;""двойные кавычки;< >угловые скобки;`машинописный апостроф, одинарная (косая) кавычка.
Подробнее о спецсимволах в Интернетах:
- Название спецсимволов at DuckDuckGo
- special characters names at DuckDuckGo
- List of Unicode characters - Wikipedia
Некоторые спецсимволы, в некоторых более старых визуальных редакторах, могут просачиваться в код без должного ХТМЛ-преобразования, что может послужить причиной некорректного отображения веб-страницы, а таже создаст проблемы при необходимости обработки текстов регулярными выражениями.
Мета описание и Ключевые слова
Что делать с Мета описанием и Ключевые слова?
Да можете ничего не делать, или напишите туда, как Вы провели это лето и спецсимволов туда побольше...
Обычно в Мета описание вставляем вступление материала, текст первого абзаца, и через запятую Ключевые слова от слов "ключевые слова" отражающие суть материала (например: говно-код, ХТМЛ говно-код) - они также будут полезны для внутренних модулей движка типа Похожие материалы и т.д.
Из Ключевые слова нахрен выбрасываем СТОП слова (и, или, на, до, после, ...).
Оба параметра обычно не должны превышать 255 символов.
Интернеты полны инфой про СТОП слова, Мета описание и Ключевые слова, находите и читайте - а мозги сношать!
админу не нужно! :)
Зачем нужны метки / теги
Зачем нужны метки / теги?
Ответ очевиден! Метки нужны для пометки. Ответ очевиден, но не для всех :)
Вот нефига ответ не очевиден. Метки для пометки. В чем эти теги участвуют? Нафига мне пометки? Чем они будут отличатся например красный светодиод 1Вт и зеленый светодиод 1Вт? Это как ключевые слова? Светодиод зеленый, светодиод красный?
В чем эти теги участвуют?
Участвуют они в организации и структурировании материалов, а также внутренней перелинковке статей.
Внутренняя перелинковка - это один из методов СЕО оптимизации, создание ссылок на одной странице сайта ведущих на любые иные веб-страницы того же сайта.
Чем они будут отличатся...?
Смысловым содержанием имени тега/метки и будут отличаться.
Это как ключевые слова?
Что-то типа того.
Если на сайте (магазе) куча товаров в широком цветовом диапазоне, неважно то носки/сапоги или трусы/лифчики, то страницам товаров можно присвоить соответствующие цвету метки, например: красный, синий, зелёный.
НЕнужно делать/плодить лишние теги типа: красные трусы, синие трусы, зелёные лифчики и т.п. Достаточно метки с названием только цвета, которая будет назначена и трусам, и лифчикам с сапогами!
Если товары свалены в одну-две категорию, без подкатегорий, скажем Одежда / Обувь, то дополнительно можно назначить метку с именем товара: трусы, лифчики, сапоги и т.д.
В популярных движках Интернет-магазов есть фильтры для выборки товаров по цвету например, но работают они в пределах отдельно открытой категории/подкатегории. Например, когда открыто Одежда - Нижнее бельё - Трусы, то выборка товаров по цвету будет только в пределах категории Трусы. Кроме того фильтры ещё нужно уметь правильно настроить в админнистративной панели магаза.
Как теги влияют на СЕО?
Да хрен его знает. Некоторые предпочитают полностью закрывать индексацию в файле robots.txt, но более феншуёвым вариантом будет <meta name="robots" content="noindex, follow">.
Зачем метки закрывать от индексации?
Смысл в том, чтобы не засорять результаты поиска, а главное предоставить пользователю ссылку на страницу самого товара/материала вместо ссылки на кучу других ссылок среди которых юзеру придётся продолжать искать... Кроме того, страница листинга товаров/материалов по метке может быть довольно динамично изменяемой пополнением новых элементов и из-за устаревшего кеша поисковой системы юзер может попасть совсем не туда куда ожидалось, закроет страницу и безвозвратно покинет сайт. То же самое относится и к категориям/подкатегориям.
Поисковым системам по-барабану инструкция <meta name="robots" content="noindex, follow">, например в справке гуглбота было написано, что noindex ему не указ и если он сочтёт нужным, то страница будет проиндексирована. Некоторые боты могут даже игнорировать и robots.txt.
Итак, теги они же метки:
- нужны для пометки;
- могут быть заменой (аналогом) категориям;
- участвуют в организации и структурировании материалов, а также внутренней перелинковке;
- объединяют товары/материалы по общему признаку: форме, цвету, назначению;
- в своём названии должны содержать краткое имя общего с другими товарами признака (форма, цвет, назначение): треугольный, красный, труселя;
- алиас метки/тега желательно должно быть на английском (не транслите), для тега красный алиас red, для квадратный square - это делает ссылку короче, размер занимаемый в БД меньше, а выполнение запросов быстрее;
- страницы (УРЛы) меток желательно закрывать от индексации для повышения релевантности результатов поиска, а также снижения нагрузки на сайт.
Те, кто из выше перечисленного так ничего и не понял, могут поискать в Интернетах альтернативные варианты пояснений по теме зачем нужны метки теги.
Файловая структура
Любой ХТМЛ говно-код неразрывно связан с ФС (файловой системой) - это вставка в него файлов стилей/шрифтов/скриптов/изображений.
Печальный случаи, когда юзер складирует все изображения в один каталог, - всё разом и до пэрэмогы
.
При том складирование происходит в режиме huяk-huяk - это когда загруженный контент не оптимизируется, потом не используется и/или остаётся там мёртвым грузом после удаления поста.
В конечном итоге, спустя пару лет в каталоге образуется свалка из десятков тысяч файлов, где найти ничего не представляется возможным по той простой причине, что оно не отображается веб-бразузером.
Содержимое такого каталога в том же визуальном редакторе не отображается веб-бразузером, опять же.., по той простой причине, что превышаются лимиты на сетевые соединения и запросы, - анонируем в гугле:
- linux network connections limit (Linux TCP/IP connections uses file descriptors)
- browser network connections limit (network.http.max-connections -> 256)
- apache network connections limit
- apache concurrent connections (MaxClients)
- apache concurrent request (MaxRequestsPerChild)
Рекомендация по структуре каталогов:
- грузить в каталог максимум по 200-300 файлов;
- структуру каталогов под изображения/файлы планировать исходя из числа материалов в год/месяц и/или сортировать по тематикам;
- images/post/2023 - если всего 200-300 файлов за год;
- images/post/2023/[1-12] - если 200-300 файлов за каждый месяц, нумерация каталогов от 1 до 12;
- изображения можно закачивать в каталоги прошлого года/месяца если условный максимум их количества ещё не достигнут.
Имена и расширение файлов
Не менее изжеванная и не раз выплюнутая, но от того не менее болезненная тема - это имена файлов и каталогов.
Мнение Клиента:
Может с названием в данном случае и перебор но в целом я не согласен. В топе выдачи картинок у Гугла картинки с максимальным описанием, заглавными буквами и черточками между словами
Регистр символов с чёрточками между словами НИКАК не влияет на результаты поисковой выдачи! Аналогично, как и регистр символов в номерных знаках машины или надписи на ракете НИКАК не влияет на её скорость перемещения в пространстве - это факт!
Скажем больше, даже смысловая нагрузка имени файла НЕ ГАРАНТИЯ попадания изображения в ТОП. Например, давайте запросим "хтмл говно-код": в ТОП-е изображение https://govnokod.ru/images/brand.gif - в имени которого все буквы маленькие и нет ни малейшего упоминания, а ни про гавно, а ни про код!
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
Кроме того, в ТОП могут попадать изображения с цифровым 16-32 значным хешем вместо имени. У поисковых систем много других более результативных инструментов для оценки ранжирования результатов, среди которых ещё и распознавание самих изображений:
Как выполнять поиск по изображению в Google - Android - Cправка - Google Поиск
Как выполнять поиск по изображению в Google
Google Объектив позволяет находить сведения об изображениях и окружающих объектах. Например, если вы ищете информацию о растении или похожие изображения с ним, то можете сфотографировать его и выполнить поиск по снимку.
Однако, смысловую нагрузку имени файла с чёрточками никто не отменял, но в пределах разумного - 8-16-32 символа!
Реальный пример, когда длинные имена мешают:
- в закачке файла с именем из 83 символов (включая расширение .apk) на СД-карту вай-вай модема - было отказано без пояснения причин.
org.mozilla.firefox_68.11.0-2015711851_minAPI21(arm64-v8a)(nodpi)_apkmirror.com.apk - файл с именем из 67 символов (включая расширение .apk) на СД-карту закачан успешно.
org.mozilla.firefox_68.11.0-2015711851_minAPI21_arm64-v8a-nodpi.apk - а вот при попытке переименовать и вовсе выдало: Can't be empty or more than 25 characters!
Рекомендация по именованию файлов:
- имена файлов всегда маленькими буквами и без пробелов;
- длина имени файла максимально коротко, 8-16-32 символа;
многие файловые системы имеют ограничение на длину имени в пределах 255 символов, но многих говно-кодеров это не останавливает;
некоторые гаджеты не принимают файлы с именами ндлиннее 25-64 символов; - чем короче и информативнее имя файла, тем быстрее будет работать ФС и поиск файлов на ней;
- расширение у файла изображения должно быть одно ИМЯ.jpg, а не несколько сразу ИМЯ.gif.jpg, исключением могут быть архивы двойной упаковки типа ИМЯ.tar.gz.
Оптимизация и сжатие файлов
Когда попадает пост с десятком безполезных изображений размером по 2-5 МБ, а у тебя трафик платный, то можете себе примерно представить набор слов в адрес автора создавшего материал!
В настройках uBlock есть фича Поведение по умолчанию -> Блокировать медиа-элементы больше 50 КБ - это по-умолчанию, но в пределах разумного этот параметр можно установить в 150 КБ.
Если ты делаешь сайт только для себя, под свой супер-компьютер с безлимитным оптоволоконным Интернетом, то можешь и дальше продолжать вставлять неоптимизированные изображения и не сжатый контент.
Рекомендация по оптимизации и сжатию файлов:
- ширина изображения +- 800 пкс;
- максимальный размер изображения 50-150 КБ;
- если изображение слишком большое и его оптимизация лишена смысла, например невидны многие важные детали, тогда лучше вставить не само изображение, а ссылку на него;
- если к материалу прилагается больше 2-3 файлов, то кроме ссылок на каждый файл отдельно, желательно упаковать их все в один архив с сжатием выше среднего.
Подготовка текста
Как уже упоминалось большинство предпочитают тексты не писать от себя из головы, мозга наконец, а тупо копи/пастить с других сайтов.
Некоторые ещё есть, которые тексты пишут сами, и бывает пишут прямо в окне визуального редактора на сайте, что на мой взгляд не практично, а также опасно потому, что:
- визуальный редактор написан на скриптах JavaScript, и при малейшем изменении в окне редактора они (JavaScript скрипты) начинают обрабатывать события потребляя при этом ресурсы ЦП в пределах 20-30% (при активном наборе текста);
- при внезапном конце света или глюках браузера уже написанное может быть навсегда потеряно.
Потому, подготавливать текст материала лучше всего в текстовом редакторе с регулярным ручным или авто- сохранением изменений + в некоторых текстовых редакторах есть возможность автоматической проверки правописания.
Там, где предполагается вставка картин Репина, можно сразу вставить имя изображения вместе с расширением, например: repin-pic.jpg
Когда текст будет готов, одним куском вставить его в шаблон, сохранить и после продолжить причёсывать разметкой базовых тегов (жирный/курсив/код/изображение и т.д.), но БЕЗ СТИЛЕВОГО ОФОРМЛЕНИЯ, - стили должны быть в CSS файлах!
Поиск и замена
Не визуальным редактором единым...
Для разметки ХТМЛ тегами больших кусков материала целесообразно будет использовать такой инструмент как Поиск и замена часто доступный в любом текстовом редакторе.
Более продвинутые авторы могут применять регулярные выражения - это отдельная и обширная тема.
В противном случае, размечая большие посты при помощи только визуального редактора, можно незаметно к йо.аной матери состариться и помереть нах..!
Алиас материала
А что надо от Алиас? Я не знаю, менять или оставлять. Гугл говорит что это вроде никнейма для статьи
- это, как пожелаете. Гугл правильно говорит.
Главное не метод, важен результат!
Алиас может быть каким угодно, хоть полностью цифровым, главное, чтобы содержимое самого материала было читабельным.
Однако, желательно чтобы Алиас был:
- чем короче и информативнее, тем лучше;
- читабельным - это поможет всем (читателю или поисковику) понять о чём материал глянув лишь на ссылку;
- отражал тематику материала;
- на латинице;
- без пробелов.
Чем короче и информативнее основной заголовок материала, тем удачнее из него получится автоматически созданный алиас на латинице.
Большинство оставляют алиас как есть - автоматически созданный после сохранения статьи.
Но, ведь можно сделать алиас короче, откинув стоп-слова, например для данного заголовка ХТМЛ говно-код или о том, как не нужно делать может быть два варианта алиаса:
- auto:
html-govno-kod-ili-o-tom-kak-ne-nuzhno-delat - handmade:
html-govnokod
Сдаётся мне созданный ручками вариант алиаса №2 более максимально краток и понятен, будет занимать минимум в БД и окружающем Интернет пространстве.
Если сайт мультиязычный, то одного и того же алиаса достаточно для всех языковых версий, например интернационального "selecting-a-driver-for-leds". Тогда проще будет ручками находить нужную версию сменив в УРЛ всего две буквы с uk на ru или en, вместо того чтобы выполнять поиск!
Пустые строки
Часто встречаются пустые строки из тегов <p> </p> или многочисленных <br /><br /><br />.
Здесь напрашивается вопрос: Друг, неужели тебе не видны большие зазоры/промежутки между текстом!? Редактор же на что тебе дан визуальный!?
Абзацы табуляцией
Ещё одно гениальнейшее изобретение - отступы в абзацах табуляцией, когда после нажатия Enter (обычно новый параграф создаётся) ты следом нажимаешь Tab и вставляешь в начале параграфа 4 пробела: <p> Текст абзаца...</p>
Теперь представь, нафигачил ты материалов с такими отступами, а потом захотелось тебе изменить величину отступов, - что будешь делать?
ПРЕКРАТИТЕ заниматься таким садо-мазо и НЕ ДЕЛАЙТЕ абзацы табуляцией! Отступы в абзацах прекрасно регулируются CSS стилями:
/* css for paragraph indent */ .com-content-article__body p { text-indent: 30px; }
Заголовки по-центру
<h2 style="text-align: center;">С чего нужно начать выбор драйвера</h2>
Аналогично отступам в абзацах, прекрасно регулируются CSS стилями:
.com-content-article__body h2, .com-content-article__body h3, .com-content-article__body h4, .com-content-article__body h5 { text-align: center; }
Размер шрифта и цвет текста
Та же песня, что и с отступами в абзацах и заголовками по центру.
Используемые на постоянной основе во всех текстах стили должны быть вынесены в файлы CSS стилей шаблона сайта!
В самом же тексте применять стиль к ХТМЛ-тегам только при особой на то необходимости в редких случаях.
За<span>енный текст
Это когда примено такое ХТМЛ-говнище тегов вокруг нескольких слов:
</span></h4> <h4><span><span style="font-size:10pt;"> <span style="font-size:10pt;"> <p> <span> </span></p> <strong><strong><strong><span><span><span>КУЙ - ЦЕНТР ВСЕЛЕННОЙ</span></span></span></span></strong></strong></strong></span></p> <p> <span> </span></p>
Валидация ХТМЛ
Валидация нам только снится.
Говно-кодеры обычно непаряться с проверкой своих творений на соответствие стандартам, и почти нет сайтов, страницы которых соответствовали бы стандартам.
Для проверки говно-сайтов на соответствие стандартам есть веб-сервис:
Зачем так вылизывать
Если у кого-то остались вопросы в стиле Зачем так вылизывать, что это даст?
, значит тот невнимательно читал вышеизложенный текст!
Алкаш: Сколько стоит капля водки? Продавец: Да ничего не стоит. Алкаш: Тогда накапайте мне стаканчик.
Некоторые моменты кто-то посчитает несущественной мелочью - возможно так и есть, если проект кратковременный и состоит из нексольких страниц. В долгосрочной же перспективе, мелочи могут накапливаться в тонны (гигабайты) ГАВна и обеспечить нехилый геморрой, от которого потом никакой Релиф не поможет.
Ещё один поучительный пример про мелочи: Меняли лобовое стекло в самолёте. Заменили 4 болта, вместо которых поставили болты на какие-то там сотые доли милиметра меньше. В результате все болты сорвало, стекло вылетело, самолёт чудом успешно приземлился.
Данный материал необязателен к практическому применению, и каждый сам себе ответит на вопросы в стиле, - зачем?:
- мыть руки перед едой;
- мыть и подтирать зад после ...;
- следовать стандартам ХТМЛ и принципам объектно-ориентированного программирования.
Уже вижу, как где-то вдалеке в мою сторону местами начинают лететь камни за применение выражения объектно-ориентированное программирование для ХТМЛ разметки и ЦСС стилей, как и называние ХТМЛ - кодом.
Выражение объектно-ориентированное программирование обычно принято применять к низкоуровневым языкам программирования типа С/С++ и т.д., ХТМЛ принято считать разметкой, но в контекстном меню браузеров есть пункт Просмотр кода страницы, а не Просмотр разметки страницы - это во-первых.
Во-вторых, ничто не мешает применять тот же принцип при ХТМЛ разметке текста и стилевом её оформлении с помощью ЦСС, как впрочем применять его же и в реальной жизни используя различного рода коробки для сортировки и хранения, органайзеры, многофункциональные чехлы и прочие штуки для упорядочивания и структурирования барахла или носителей информации.
