Напоминает ситуацию из мультика про Маугли. Там тоже Медведь учил мальчика бегать на четырех лапах, так мол правильней.
Но верстальщик же человек)
Он бегает ногами и работает руками)
aliasst: хотя да, согласен. Там видимо какие то нюансы есть с baseline. Но у картинок есть ширина и высота, даже если явно их не указать. Тут разница в типах контента inline-flow(вроде) у спана и inline-replaced у картинки
Worddoc: я таких книг, к сожалению, не встречал. Можешь попробовать почитать статью how browsers work, но там много ненужных обычному фронтендеру технических деталей. Некоторые крупицы информации возможно окажутся полезными. Для качественной анимации тебе надо по любому копать в сторону requestAnimationFrame, так что вбивай в гугл и читай последние туториалы по этой теме (возможно уже есть более продвинутые способы, но там наверняка еще плохая поддержка браузерами)
Worddoc: у тебя там ошибки вроде (jquery плохо знаю)
Во первых - body вынеси в переменную и сравнивай в условии эту переменную, а не ищи этот элемент каждый раз в dom.
Во вторых - у тебя есть переменная elem, но далее по коду ты обращаешься к ней через $(elem), а надо просто как elem.
Ну и третье - найди в инете пример использования requestAnimationFrame и перепиши код аналогично.
PS. Раз ты пользуешься jQuery, то возможно более разумным будет использовать уже готовый плагин.
Worddoc: возможно у тебя в функции есть код медленный. Всякие getElementByID и т.д. должны быть обязательно вынесены за пределы этой функции, чтобы минимизировать обращения к dom. Выложи кусок кода, который выполняется внутри if - посмотрим
Sergey GoryachevСергей: и зачем нужна семантика?) Каково практическое назначение?) Интересно услышать конкретные аргументы, а не мантры евангелистов, которые гуляют по статьям в интернете.
Вот выдержка из спецификации:
The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content. Each section should be identified, typically by including a heading (h1-h6 element) as a child of the section element.
Прошу обратить особое внимание на требование иметь заголовок внутри section (в общем это касается любого sectioning element)
Если везде вставлять этот section, то валидатор будет выдавать такую ошибку - Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.
Так-как не все разделы лендинга имеют заголовки, то и решение использовать section для этих целей не лучший вариант. Вся эта мишура типа article, section и т.д. была придумана для разбиения всяких текстовых документов и большинство лендингов/интернет-магазинов могут легко обойтись без такой "семантики".
Что такое section по-сути?
Это обычный div со вшитым role=region
Все это секционирование не поддердиватся ни одним браузером и реализовано только в валидаторах.
Короче, лучше уделяйте внимание SEO оптимизации сайта, чем заморачивайтесь решением надуманной проблемы. Поисковикам пофиг на всю эту семантику. Людям с ограниченными способностями можно создать отдельную версию сайта(WCAG 2.0, пункт 136 разрешает такой подход). Все прочее - от лукавого)
Денис Киселев: на мобиле эта пропорциональность выльется в слишком мелкий шрифт. Думаю там надо кардинально перестраивать расположение надписей, смещая их вверх и вниз вместе с линиями
Dark19: по поводу ретины - в этом и есть ее особенность. Чтобы не увеличивать разрешение экрана до бесконечности, в эппл решили пойти другим путем - увеличивать плотность пикселей и сохранять разрешение на уровне 1280 или 1366 пикселей.
По поводу макета, то не сильно важно какой размер. Он же не будет требовать чтоб на мобиле отображалось как на большом экране, тогда и не стоит требовать чтоб на 1280 экране отображался 1920 макет
Тогда верстальщик делает часть твоей работы)
Возьмем пример из трех блоков - как их адаптировать задумывалось?
На планшете их можно построить как 50% - 50% - 100%, или как 50% - 50% - 50%, или даже как 100% - 100% - 100%. Как быть верстальщику?
К тому же, если не согласован мобильный макет с клиентом, то у него остается пространство для маневра, типа - мне не нравится как выглядит на мобиле - переделывайте!
Dark19: Если макет был 1 к 1 (что скорее всего так и было), то у клиента просто монитор не может отобразить брейкпоинт в 1600 пикселей и тут нет твоей вины.
Для ретины только картинки имеют значение. Все остальное аатоматически конвертируется.
Самое главное это задавать размеры в CSS для всех растровых элементов. Если ты не укажешь для картинки размер в CSS, то она станет в два раза меньше чем остальные элементы на ретина экране. Остальные элементы типа шрифтов или всяких блоков автоматически подстраиваются, так как у них проставлен размер в CSS.
Короче, на макбуке 13" - физических пикселей 2560 (нам это не важно), но в браузере их всего 1280 (это важно). У клиента устройство с 1280 пикселями в ширину и естественно он не может увидеть брейкпоинт на 1600 пикселей.
По поводу фразы на сайте - это они меряют в физических пикселях, но как я уже выше сказал - физические пиксели нас не волнуют, В браузере все отрисовывается по CSS пикселям.
Dark19: на макбуке просто нет такой ширины как 1680
Дело не в ретине.
Там вроде ширина экрана либо 1360, либо 1440 (точно непомню)
В общем он сможет увидеть этот брейкпоинт только на экране с шириной больше 1680
Dark19: если ты уменьшал размеры, то значит изначально у клиента все было больше на ретине чем должно быть?
Еще такой момент с пикселями - они сами по себе могут быть разного размера на разных устройствах. Например у меня на макбуке 100 пикселей выглядят примерно как сантиметр в ширину, а на айфоне - примерно как 0.75 сантиметра. На каком устройстве он проверяет?
Dark19: пиксели не имеют отношения к делу. В итоге все так и так переводится в пиксели в браузере. Ремы и проценты это просто для человеческого удобства сделано, чтобы задавать относительные размеры.
Dark19: в css указано 1925 пикселей ширина?
Если да, то клиент что то путает, ибо все должно отображаться нормально у него. Уточни еще плиз какое устройство. Может там и не ретина вовсе, а 4к вообще и он сам не понимает как оно должно отображаться.
