Pull to refresh

Comments 49

Замечания по верстке:
Идеальная верстка должна выживать где-то в районе IE6. Стараемся по минимуму использовать inline-block. Заранее смотрим, что будет если он станет inline или block элементом.
Position — это опасно. Желательно ничего никуда не позиционировать.
Float — тоже к добру не приведет. Желательно вообще про него забыть.

очень спорно.

А так полезная статья, всегда интересно увидеть чужие стандарты ;)
Тоже не совсем понял сей момент. Это был призыв верстать таблицами?
Нет. Но иногда таблицы нужны. Например есть тренд верстать не таблицами. Но и таблица может помочь вам выживать при конвертации в EXE. Просто нужно к ним относиться проще. Иногда они нужны, иногда не нужны. По возможности — лучше конечно без них. Но иногда делают кучу костылей, лишь бы только таблицу не вставить. Вот вам немного HTML -> CHM:

image

Ссылка http://bakhirev.biz/StalinGrad/demo/31.zip

А вот теперь представьте, что у меня есть всякие менюшки, окошки, диалоги. И я хочу чтобы это работало 100%. Без таблиц такой финт не сделать. Но опять подчеркну, что они нужны в случаях крайней необходимости и спец. условиях. Сайты всяким ООО Рога и Копыта — конечно нужно верстать без них по HTML5 семантике.
UFO just landed and posted this here
Нафиг-то оно, конечно, нафиг, но делать пуленепробиваемую обвязку гораздо быстрее таблицей.
Речь идёт об одной таблице безо всякого колдунства против нормальной такой пачки стилей.
Так что лично я бы обошёлся без фанатизма и делал как проще (в т.ч. и в поддержке!), а не как «современнее».
UFO just landed and posted this here
Думаю, что ее не «скрутит» от щелчка мыши по менюшке ;)
Переименуйте статью в «Набор костылей для мобильных устройств».
Странно почему мы вспоминаем про IE6/IE7 в статье про мобильные устройства, действительно странно
Переименуйте статью в «Набор костылей для мобильных устройств».

«Набор костылей для приложений для мобильных устройств».

Многое из описанного банально вредно, если вставить в обычную страничку.
Очень спорные стандарты на самом-то деле

Как уже писали выше, про inline-block и float довольно странное напутствие. По поводу inline-block все не так уж и плохо: его можно заставить работать в IE6. Если мне не изменяет память делалось это указанием следующих стилей
.inline-block {display: inline; zoom: 1;}
В IE7 конструкция выше работает точно. Многие SASS/SCSS фреймворки (Compass, Bourbon, …) имеют mixin inline-block, который как раз и реализует данный хак для старых IE

Да и опять же, вы в статье упоминаете про Progressive Enhancement и Graceful Degradation и в тоже время призываете отказываться от того же inline-block и прочих вещей. Подключив modernizr, вы сможете тестировать поддержку различных css возможностей и при необходимости менять их отображение. Также modernizr хорош для проверки placeholder, pattern, упомянутых в статье для input. Верстка, выжившая для IE6, но без нужных полифилов, будет смотреться странно, особенно если все подписи к полям существуют только в виде placeholder, потому что ни одна подпись в input'е не покажется. Это, кстати, касается и IE8.

По поводу noscript. По спецификации HTML5 данный тег запрещен. Вместо него сейчас принято добавлять к html класс no-js, а у браузеров которых включен JS снимать этот класс. Используя этот подход, можно отображать/не отображать какие-то блоки, а не просто добавлять дополнительный текст, как это делает noscript. С классом no-js все легко контролируется через CSS. Также вы сможете менять функционал своего приложения, проверяя включен ли JS. Делать, к примеру, формы по умолчанию рабочими на отправку, но если включен JS и нужна поддержка ajax, то делать preventDefault и отправлять форму ajax'ом и тп.

От reset.css уже многие отказались в пользу normalize.
Упомянутый выше modernizr также включает в себя html5-shiv, поэтому нет необходимости подгружать его отдельно, если используется modernizr. Выше вроде бы как указаны плюсы его использования.

Если идти в сторону микроформатов и разметки учитывающей все, то необходимо также добавить информацию для соц. сетей в head
Сейчас самый известный формат для этого — Open graph ogp.me/. Его поддерживает Facebook и по ощущениям VK тоже
Для твиттера тоже появилась подобная возможность — dev.twitter.com/docs/cards
Неправда. Спецификация WHATWG, Спецификация W3C.


Да действительно, я ошибся, извиняюсь. Не успел тщательно перепроверить информацию, почему-то давно запомнилось что его запрещали. Буду в курсе, что в итоге он рабочий.
Зачем запрещать маштабирование? Это же неудобно когда маленький экран.
Ну в идеале верстальщик должен предусмотреть маленькие экраны и сделать их удобными без маштабирования. Кнопки увеличить, лишнее убрать и т.д. Например, мы пользуемся обычными мобильными приложениями без маштабирования, т.к. они хорошо заточены под экран -> ну а страничку оптимизировать гораздо легче.
Чтобы случайно не зумить приложение, использующее webview устройства. Если контент уже оптимизирован, в том числе и под маленький экран, зум будет неожидаемым и излишним поведением. Представьте себе, что демка с грибом запущена на мобильнике (при этом растянута на весь экран) и двойной тап — прыжок. Пользователь дважды тапает и… зумится :)
Отключение масштабирования и отключение кеша выглядит злом.
Если это мобильное приложение (еще раз повторюсь — приложение) то все файлы у вас уже лежат на устройтсве, а не тянуться через интернет, также ваше приложение уже оптимизированно для мобильного просмотра и зум лишь будет мешать и портить сайт. Напишите игру на html5 для смартфонов и скажем воспользуйтесь phoneGap вы поймете, что в отключении этих параметов есть смысл.
Вот начитаются начинающие «веб-разработчики» таких статей, вобьют себе в голову всё написанное как постулаты, и будут бездумно фигачить именно так, потому что умный дядя из интернетов сказал, что это правильно. Все приёмы, освещённые в статье, нужно использовать с умом, зная, когда это нужно, а когда нет. А в данном случае подача именно «некогда объяснять, просто делай так».
Ну и присоединюсь к недоумевающим от того, что вы решили запретить людям использовать float, position и inline-block.
UFO just landed and posted this here
А я скажу больше, если вы верстаете например шапку сайта, часто элмеенты там расположены не структурно а в угоду юзабилити и потребностям маркетинга, в данном случае я счтаю использования позиционирования даже обязательным, ибо так вы решаете кучу проблем с частыми правками этого блока (например: добавление стикера с акцией, добавления логотипчика праздника (новый год, 8 марта...) и прочих временныъх элементов), также в подобных частях сайта изменение элемента на пару пикселей не должно вдруг сдвигать все другие за пределы области или на другие строки.
Так что везде нужен разум
А разум приходит тогда, когда начинаешь верстать не «картинку», а логическую структуру.
Так, это, есть места где важна картинка именно ну и к тому же позиционирование никоем образом на структуру не влияет у вас может быть прекрасный, логически выверенный валидный и сематичный html, с поддержкой решений для людей с ограниченными возможностями. Но при этом ничто не мешает визуально его оформлять с помощью абсолютного позиционирования дабы было удобней и избежать возможных проблем
Я, видимо, не совсем правильно выразился. Я имел ввиду не столько семантику, валидность и прочее, сколько… скажем, логическое взаимоотношение элементов на странице. То есть если элементы логически взаимосвязаны (их расположение/размеры зависят друг от друга), то нужно учитывать в первую очередь это, а не то, какая в итоге должна получиться картинка. То же самое относительно несвязанных элементов — не за чем городить огород из отступов и полей, если можно использовать абсолютное позиционировние, т.к. элементы друг на друга никак не влияют.
В общем, кажется, мы говорим об одном и том же =)
Мне кажется вы выбрали неверный хаб — Веб разработка.
Раз уж эти советы касаются приложений, которые имеют малое отношение к вебу каким мы его привыкли видеть. Большинство ваших советов похоже на костыли, а с некоторыми можно спорить, в контексте веба, но, возможно, не в контексте разработки мобильных приложений.
Вот пожалуй и все. Тем кто осили — небольшой бонус:
В демке вы можете посмотреть все meta теги из статьи.

Для каких браузеров предназначена демка? Попробовал в Хроме 33 и FireFox 27 — жутчайшие тормоза и дёрганье на не самой слабой по сегодняшним меркам машине. У меня Quake 1 в браузере на той же машинке работает без тормозов, а тут какой-то платформер…
Хз, у меня даже IE6 без тормозов гоняет. Проверил на паре ноутбуков.
Если вашему комменту сейчас «лайков» не наставят — тогда что-то у вас на компе не так. Если будут плюсовать — тогда буду разбираться в чем баг.
А подскажите, пожалуйста, где лучше всего дополнительно почитать про переносы — я несколько раз пытался их у себя завести (в том числе и сейчас после вашей статьи), но, видимо, упускаю что-то важное — в последнем Хроме под Линуксом у меня на тестовой странице никаких переносов не появляется, несмотря на добавленные в css hypens: auto.
Сам себе отвечаю: в Хроме на данный момент и в ближайшей перспективе hyphens не поддерживаются.
А как на счет вашего форка бойлерплейта на гитхабе?
user-scalable=no
Будьте осторожны, советуя это. Сейчас набегут любитеги готовых решений и вставят это на все свои сайты, которые совсем не приложения и я в очередной раз не смогу выделить или прочитать мелкий текст.

Таким образом браузер может более корректно расставлять переносы
Не более корректно, а в принципе сможет. Без этого никаких переносов.

HTML по ГОСТ`у
По ГОСТу.

Расческа для CSS (http://csscomb.ru/online/)
Лучше используйте новую версию csscomb.js — она, в отличие от той формы, развивается, лучше работает и имеет таск grunt-csscomb.

Тем кто осили
Мобильный хром позволяет переопределить столь нехорошее и часто неудобное для пользователя поведение.
Это все равно не совсем правильно — можно и размер шрифта делать крупнее через настройки браузера, но верстка, как правило, на это не рассчитана.
Если есть необходимость в более крупном шрифте на сайте — эта возможность должна предоставляться интерфейсом сайта.
Если сайт должен масштабироваться — это тоже должно быть предусмотрено со стороны разработчиков.

А вообще сейчас по-моему такие сайты для телефонов делают, что в масштабировании на них нет необходимости.
Спасибо, очень интересная подборка.
На счет добаления img — vertical-align: top, не совсем соглашусь т.к. зачастую приходиться выравнивать картинку по middle
<link rel="apple-touch-icon" sizes="72x72" href="images/touch-icon-ipad.png"/>
<link rel="apple-touch-icon" sizes="114x114" href="images/touch-icon-iphone-retina.png"/>
<link rel="apple-touch-icon" sizes="144x144" href="images/touch-icon-ipad-retina.png"/>

Apple изменила размеры, теперь так:
<link rel="apple-touch-icon" sizes="76x76" href="touch-icon-ipad.png">
<link rel="apple-touch-icon" sizes="120x120" href="touch-icon-iphone-retina.png">
<link rel="apple-touch-icon" sizes="152x152" href="touch-icon-ipad-retina.png">

Safari Web Content Guide:Configuring Web Applications
-webkit-text-size-adjust: none; отвечает не за выделение в CSS, а за автомасштабирование шрифтов, если браузеру «покажется», что шрифты нужно увеличить. Отнести этот стиль нужно скорее к масштабированию. При отсутствии данного стиля (на моих страницах) iPhone самопроизвольно менял размер шрифта при изменении ориентации на горизонтальную, оставляя размеры всех элементов (не текста) правильными. При загрузке страницы сразу в гор. позиции всё было нормально. Возможно, в вашем случае это проявится по-другому, в детали не погружался.
<meta name="viewport" content="minimal-ui" />

Благодаря ему, в Сафари в iOS 7.1 адресная строка дёргаться не будет при скроллинге вверх-вниз, а всегда будет с фиксированным размером. Пример.
вот так вот и появляются пустые страницы в добрый десяток килобайт. А ведь она еще без контента
UFO just landed and posted this here
boilerplate переводится как «шаблонный», т.е. наборы каких-то готовых рецептов для HTML5
а пуленепробиваемый по-английский будет bullet proof

ну и статья целиком посвящена мобильным веб-приложениям. об этом надо писать хотя бы в предисловии. а то начинаешь это понимать только к середине

плюс, много спорных вещей, о которых уже сказали выше
Сильно же вас жизнь потаскала, все эти мета-теги знать.
Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/)

boilerplate == шаблон, заготовка
Тоже мне, стандартизеры нашлись:
Демка даже валидацию не проходит:
Result: 6 Errors, 2 warning(s)
Внутри самой странички в теге <style> закрывающую фигурную скобку потеряли.
Я уж не говорю о том, что просто тупо открытая в браузере страничка с демкой за 1 час «прокачала» 75 мегабайт ЖПРС трафика. вообще пипец.
Sign up to leave a comment.