Заметки на полях…
Салют! Вот я и закончил дорабатывать новую тему оформления блога, ну «закончил» это громко сказано, скорее «достиг определенного уровня удовлетворения». Переход на новое оформление оказался не самым легким, так как я преследовал одну хитрую цель, еще мной неизведанную. Это — адаптивность, то есть возможность темы оформления подстраиваться под любой размер окна, не теряя при этом функционала и удобства использования. Признаюсь: цель мной достигнута не вполне. По крайней мере те возможности адаптивности меня пока что не совсем устраивают, поэтому в этой части блог будет еще дорабатываться.
А подробнее остановится я хочу на других вопросах, а именно: внедрение шрифтов Google Fonts и их влияние на скорость и отображение контента, тестирование новой темы оформления в разных разрешениях, баги и глюки, которые вылезли в процессе тестирования. А также скажу несколько слов о валидности кода. И начну я с последнего — с багов и глюков.
Как я боролся с глюками
Как вы уже могли заметить блоки с анонсами постов на главной странице — плавающие, то есть при смене размера окна и/или разрешения экрана они плавно сползают туда где им место, чтобы не вылазить за пределы окна. Это и есть та самая адаптивность. Так вот первый баг, который я встретил это то, что эти блоки поругались с боковой панелью — они залезали на нее и перекрывали собой. Это и сейчас можно наблюдать если изменять размер окна до небольшого размера. А все потому что в этой теме оформления и в помине не было никакой боковой панели изначально.
Признаюсь, это была уже готовая тема оформления для WordPress под названием Pinbin (официальная страница темы), вот посмотрите как она выглядит по умолчанию:
Все те же блоки «а-ля Google+», собственно из-за которых я взял ее для своего блога, но как видите в ней нет сайдбара. Механически добавить сайдбар оказалось несложно: в файлы темы оформления single.php, page.php и index.php я добавил следующий код:
<div id="my-sidebar"><?php dynamic_sidebar( 'pinbin_footer' ); ?></div>
В папке с темой оформления создал файл sidebar.php со следующим содержимым:
<?php if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('sidebar_right') ) : ?>
<?php endif; // endif widget ?>
<div class="clr"></div>
В файле style.css естественно прописал стили оформления для #my-sidebar, сами стили я тут приводить не буду — кто знает, тот найдет, а кто не знает — тот спросит. Далее через стандартный апплет добавления виджетов добавил эти самые виджеты. Но сайдбар не подружился с этими самыми блоками, но этот полбеды, с блоками я его подружил довольно грубо, а вот как я не старался подружить сайдбар с полной статьей — ничего не выходило, на маленьких разрешениях ниже 1280px статья уползала вниз. Пришлось в тех же стилях в самом конце рисовать костыли для разных разрешений. Но это не адаптивность, это именно костыли и я буду их дорабатывать. но то, что уже есть — хоть какой-то результат и это радует.
Потом появился странный глюк, на который мне указал один мой друг. Вот собственно скриншоты этого глюка, которые он мне и прислал:
Обратите внимание на неравномерные разрывы между блоками — они появлялись иногда при первом входе на сайт и всегда при обновлении страницы, что жутко бесило. Вернуть блоки можно было только если пройти по любой ссылке на странице,а хотя бы щелкнуть по логотипу — блоки выравнивались как надо. Что я только не делал: и по буковке проверял и исходный код, и код файлов темы оформления, вдоль и поперек прошерстил CSS, и инспектировал соответствующими инструментами в Opera и Mozilla Firefox — нифига! Этот разрыв как заколдованный — ниоткуда. Уже хотел идти к экстрасенсам… Но тут меня, как это часто бывает, осенило (со мной иногда бывает как с доктором Хаусом — осеняет и я бегу пробовать): я сейчас часто на своих сайтах использую Google Fonts, удобно же ведь, не зависишь от того, есть ли у пользователя на компьютере тот или иной шрифт, так вот я снес вебшрифт Open Sans и поставил стандартную строчку: «Trebuchet MS», Arial, Helvetica, sans-serif; и… о чудо! — разрывы перестали появляться, во всем оказался виноват Google Fonts. Уж не знаю почему, но ни один другой шрифт из вебархива Google не подошел — все они вызывали эти разрывы, как я не игрался со стилями. Поэтому сейчас блог со стандартными шрифтами. Вооот… такие глюки иногда вылазят, что хоть святых вон выноси. Ну ладно, о глюках достаточно. перейдем к другим темам, а именно…
Веб-шрифты Google Fonts
Как я уже говорил выше последний мой опыт использования Google Fonts оказался не самым удачным, хотя на texnotron.com, на моем основном сайте спокойненько себе живет PT Sans и все отлично выглядит. ну, как говорится, раз на раз не приходится.
Так вот, вопрос стоит в том стоит ли использовать в своих проектах (читай: в коде свои сайтов) вебшрифты? Конечно стоит! мало того, что на вебшрифты переходит все больше и больше сайтов, так и сами шрифты оптимизируются, сжимаются и их количество растет. Это и другие приятности, типа межсайтового кэширования, является стимулом к использованию вебшрифтов. Вот интересная статья по этому поводу, также и ее обсуждение ниже.
Да, я не спорю, ставить тяжеловесные шрифты с несколькими начертаниями на большой текстовый сайт типа блога — не очень разумно, мобильные пользователи вас проклянут. Но вот в моем случае (на этом блоге) это был Open Sans с тремя начертаниями — довольно легкий шрифт, но дело оказалось в весе… Но это частный случай, в большинстве случаев все нормально, главное перед тем как использовать Google Fonts — поупражняйтесь, почитайте статьи как это делать правильно, статья на которую я дал ссылку выше может стать отправной точкой в изучении этой темы.
Едем дальше. И на очереди у нас…
Тестирование сайта в разных разрешениях
как правило в процессе разработки сайта, его дизайна, в процессе верстки и отладки, сайт необходимо тестировать, как минимум по двум параметрам: на совместимость с разными браузерами и на то как он отображается в разных разрешениях. Совместимость с браузерами можно провеярт с помощью «набора минимум» — с помощью установленных на компьютере браузеров. Я использую сразу Internet Explorer 9 (а на ноутбуке есть IE8), Opera (старая), Opera 22, Mozilla Firefox, Safari, Яндекс.Браузер, Google Chrome — этой гоп-компании вполне хватает для начального тестирования.
Конечно можно использовать и такой сервис как browsershots.org — указываете адрес сайта или отдельной страницы, отмечаете галочками необходимые браузеры, в самом низу задает условия, нажимаете Submit и ждете (иногда очень долго) пока сервис создает скриншоты вашего сайта из заданных браузеров. С одной стороны удобно — можно посмотреть как выглядит сайт например на другой платформе, например в Linux в браузере Konqueror; но с другой стороны — долго и иногда бывает, что скриншот по какой-то причине не получается, приходится начинать с начала.
Я раньше пользовался этим сервисом, но теперь — нет. Мне для понимания как выглядит сайт в том или ином браузере вполне хвататет установленных на моем рабочем компьютере обозревателей, также я иногда прошу друзей посмотреть от себя. И этого достаточно.
Но вот недавно я наткнулся на такой замечательный сервис как quirktools.com где есть раздел Screenfly: здесь вы можете в реальном времени проверить как ваш сайт будет выглядит на разных устройствах с разными размерами экрана, будь то ноутбук, десктоп или планшет.
Сервис этот бесплатный и очень удобный: несколько десятков реальных устройств с разными разрешениями экранов, возможность прокручивать сайт в окне выбранного устройства, возможность поворачивать экран на 90 градусов в планшетах. Довольно наглядный инструмент для тестирования сайта, особенно хорошо тем, что быстро можно перейти от устройства с большим экраном к мобильному с маленьким.
Вот и приближаемся мы к последней теме, а это у нас…
Валидность кода
Об этих двух словах уже сказано очень много, наверное даже больше чем стоило. Но жизнь такова, что… я тоже скажу пару слов о валидности кода. И, чтобы быть более лаконичным, выражу свои мысли следующими тезисами:
- валидность кода желательна, но не обязательна;
- если невалидный код работает — не трогай!
- не всегда абсолютно валидный код — хорош и функционален;
- если невалидность кода вызвана функциональной необходимостью, то не стоит рушит функционал ради валидности;
- HTML-валидатор не цель, а инструмент выявления ошибок.
Вот как-то так. Я люблю валидный код, его легче читать, он приятен глазу, его (вроде бы) любят поисковики. С помощью валидатора удобно искать ошибки в коде, которые при простом просмотре кода найти очень сложно. Валидный код помогает в достижении кросбраузерности, а это, согласитесь, важный момент. Есть такие люди, кто считает валидный код чем-то святым и стремятся к абсолютной валидности любыми путями, уничтожая функционал. Это неправильно.
Вот давайте рассмотрим то, что есть под рукой: два моих сайта этот блог kbaott.net и сайт texnotron.com (ссылки ведут на страницу валидатора). На момент написания поста главные страницы этих сайтов были валидны, в доказательство приведу скриншоты этих страниц:
Внутренние страницы сайтов я еще до конца не оптимизировал, но до них руки все никак не дойдут, а может и не дойдут вовсе — если все и так работает уже много лет.
Этой валидности я добился простым исправлением ошибок в коде. Ничего я из кода не вырезал и функционал не менял ради валидности. Просто когда первый раз открываешь валидатор и видишь 65 Errors, 142 Warnings, исправляешь первую в списке ошибку, Revalidate и уже 24 Errors, 41 Warnings, значит ты на правильном пути. И ошибки там бывают такие, что даже смешно: например с стандарте HTML5 уже не принято в тэге <img> указывать параметр border=1px, так как он obsolete, то есть устаревший, а значит нужно через стили прописывать style=»border:1px;» — это просто правило хорошего тона, браузер покажет и так и так. Но есть такие (псевдо)ошибки в коде, потерев которые, мы лишимся куска важного функционала — этого делать не нужно. Валидация ради самой валидации — это паранойя.
Или вот например CSS валидация. Тут дела обстоят несколько иначе. Ошибка на которые указывает валидатор стоит исправить, так как от этого зависит работоспособность стилей. Я поправил в своем style.css все ошибки, которые были явно мной допущены и решил сразу несколько проблем отображения. Но остались еще десяток одинаковых: Ошибка разбора opacity=100)
Ну и как мне исправить эту ошибку, если эта самая инструкция filter: alpha(opacity=100); предназначена только для Internet Explorer’a и без нее в нем не будет полупрозрачности? Да никак! Забить и все. Ведь таких хаков лично для «Ослика» очень много и удалив их, мы лишаемся кросбраузерности, а это уже другая сторона медали.
Под всем сказанным можно подвести черту и сказать: валидный код это хорошо, когда не является самоцелью.
Ну вот и все, что хотелось сказать. Я снова подтверждаю название своего блога — сейчас на часах 23:01. Всем пока, до новых встреч! Мир вам.
Вступил в клуб анонимных алкоголиков. Третий день уже бухаю и даже не знаю, с кем.
Метки: css, google fonts, html, блог, валидность, оформление, сайт
Писано 24.07.2014
