Pull to refresh

Comments 49

Решение второе рулит, только ради чего тогда была вся остальная заметка? :) В некоторых своих проектах применял по три стиля для каждого типа медиа. И как то даже в мыслях не было оптимизировать, и без того небольшие были. КОгда файлов больше 3-5 это да.

Ну - кому как.
А тем, у кого JS выключен - куковать? :)

@at-rule... rules. ;)
ИМХО, вообще это проблема браузеров :) Пусть они её сами решают, а решение на стороне сайта — это лишние костыли, которые только принесут новые проблемы.
Не согласен! Все проблемы — это проблемы разработчиков сайта. Пользователю (клиенту) интернет-системы важно, что бы все работало при любых условиях. Первый метод — это полный бред. Внимательно читайте спецификации W3C!!! Как надо делать? — Обратите внимание на новую верстку яндекса!
Да ну?
Пойду-ка напишу свой дебильный брау Internet Explorer, который будет рандомно выбирать положение блоков на странице, зайду на ваш сайт и скажу — у вас проблемы!
Я понимаю, что разработчик не должен сваливать все проблемы на клиента — клиенту нужна только услуга — ему всё равно на то, что браузеры не поддерживают стандарты.
Но решение на стороне сайта не будет эффективным в любом случае (либо всё равно загрузка будет тормозить или стили не грузиться без JS), так что единственное эффективное решение — это решение на уровне браузеров. Кроме того, проблема не настолько острая, чтобы срочно вводить «костыли» на уровне сайтов — 1—3 секунды загрузки вполне могут подождать пока разработчики браузеров учтут этот ньюанс (хотя бы сделать загрузку параллельной — ИМХО, для Mozilla текущая ситуация позор :) ).
> Обратите внимание на новую верстку яндекса!
Обратил, не лучший пример для подражания. Они принципиально не пользуются тегами <html>?
Может быть быстро сформулируете правильное решение?
У вас все корректно отображается? Лично у меня — да. А что еще надо? Главное, что бы клиент был доволен.
"Ну и что, что дерьмо, главное работает как надо." Мне не нравится такой принцип. Ни компании, которые им руководствуются, ни продукты, которые сделаны таким образом. Поскольку где-то обязательно зарыто дерьмо, которое когда-нибудь всплывет.
В принципе, я с вами согласен, но не следут забывать, ради каких целей производиться тот или иной продукт. Конечная цель того же яндекса — заработать денег, а не показать какие они крутые разработчики. Если пипл хавает, зачем тратить больше времени и денег на производство. Вы пробовали чай в Финляндии? Там он вкуснее чем у нас. Связано это с потребностями рынка. Так же и с IT. Будет надо — переделают.
NetRat, хоть это и офтоп, но расскажи пожайлуста о Финляндском чае, как называется, и где его можно купить в Москве. Можно в личку.
а у кого куки выключены и куковать несмогут
Решение второе, мне кажется не очень удачным, так как:

  1. Трудно контролировать стили, когда они все в одном файле.

  2. Конечно не будет тратиться время на запрос print.css, но всё равно придётся ждать, пока его содержимое передаться по Сети.

> Трудно контролировать стили, когда они все в одном файле
Если оно того стоит (большая нагрузка, много файлов) можно написать служебный скрипт для сборки всех файлов в один и запускать перед/в процессе выкатки.
+ gzip/deflate и кеширование на стороне браузера
Но второй минус это всё равно не исправляет ;). Всё равно придётся ждать пока не загрузятся стили для печати. А самое обидно, что при JS сжатии (если я правильно понял), когда у пользователя отключён JavaScript, то он даже дизайн для монитора не увидит :).
Сжатие CSS.
Пример с моего сайта. Он собирает все файлы (а их около 6), складывает, сжимает и кэшует.

Правда вот, gzip никак не прикручю. Руки не доходят. :)
Собственный сервер?
Можно nginx поставить, настроить на отдачу статики. Хорошо разгружает apache, легко настраивается автосжатие. Если статика не часто меняется, можно настроить на отдачу соответствующих заголовков для кеширования браузером.
> А самое обидно, что при JS сжатии (если я правильно понял)
Неправильно. Сжатие на стороне сервера, только для тех браузеров, которые понимают, автоматически и без извращений.
Юзайте @import url('css/web.css'); для отложенной загрузки стилей (если заказчик позволит так издеваться над дизайном) и php для выбора файла стилей к определенному контексту.
а в ASP.NET нужно думать над оптимизацией всего генерируемого html, оптимизация css - капля в море мусора самого html кода :(
то есть? А почему не вынести весь html в отдельный шаблон и не сверстать нормально?
потому что asp.net генерирует избыточный html код. особенно, если использовать стандартные компоненты, темы (Themes) и кожы(Skins).
помотрите ради интереса html сайта www.ufamama.ru
мда.. это действительно кошмар. Но неужели нельзя html писать самостоятельно, не полагаясь на стандартные компоненты?
Можно, но тогда пропадает все удобство от стандартных компонентов.
удобство сомнительное, а вот неудобство очевидное.
Не соглашусь. после 4 лет работы с php перешел на asp.net, работаю с ним уже 4 года и мне нравится.
я сейчас не сравниваю php и asp.net, а говорю про стандартные компоненты, генерящие кривой код.
есть такой момент, но пользоваться компонентами удобно, в браузерах он отображается корректно. есть очень гибкие возможности писать и использовать свои компоненты, которые уже будут генерировать правильный код. в общем, палка о двух концах.
Есть несколько движков под .NET, которые работают по аналогии с RoR и т.п. (более-менее чистый MVC).
Но они, увы, не поддерживаются никем, кроме создателей :)
Ходят слухи, что MS скоро сам выпустит такой фреймворк.
В наше-то время тотальных расширений домашних интернет-каналов мы все еще копаемся в проблемах диалапного прошлого? Конечно, оптимизацию, минимализм никто не отменял, но проблема, имхо, того не стоит.
По поводу кроссброузерности - библиотеки рулят.
Знаете, я с вами не соглашусь. Сейчас время на установление соединения с сервером сравнимо с временем загрузки отдельного маленького файла. Если файлов 2-3, и они достаточно большие, то об этом можно забыть. Но когда файлов много, они все маленькие, да еще и таблиц стилей десяток напихан, это, знаете, для пользователя, зашедшего на сайт впервые, очень сильно скажется.

В частности, это стоит принимать во внимание при проектирование корпоративных сайтов: когда процент возвращающихся пользователей минимален.
Я думаю, что уменьшение графики и отказ от PRных Flash-презентаций (чем как раз знамениты корпоративные сайты) скажется на загрузке страниц гораздо больше :).
это вы отделу продаж объясните, что так сайт лучше грузится :)
отказ от PRных Flash-презентаций
:) Ну работа разработчика — это лесть и обман :) Конечно согласен, что часто ситуация ужасна, но тем не менее надо стараться :) и бутылочка вина отделу маркетинга будет лучшим техническим решением скорости загрузки :)
если человек не первый раз заходит на этот сайт, ваши маленькие файлики загрузятся из кеша
предлагаю зайти на среднестатистический американский интернет-магазин и потосковать некоторое время, гдядя на статусную строку браузера с сообщением "загружено изображений: 245 из 340". Это, конечно, крайность, но попустительство к таким крайностям и ведёт.
Я к тому, что обсуждение похоже на аналог типа что лучше "echo" или "print"
да я понимаю. Но нет мелочей. Нет, и всё тут. Допустив одну мелочь, позволишь себе допустить ещё одну. А там, глядишь, докатится и до маразма с весом страницы в несколько мегабайт. А что, каналы-то нынче толстые!
Никогда не стеснялся применять больше пяти CSS-файлов на одной странице. Все стили хорошо структурированы, прозрачно разложены по папкам. Так как проджект еще сапортить и развивать надо.

В общем думаю не стоит так заморачиваться. Тем более делать работу производителей браузеров.
Правильно. Но вот, отдавая клиенту, я бы их собирал, сжимал и отдавал в один поток.
Ну это конечно можно, но плюсы тоже спорны... Много CSS-кода относится к конкретным страницам, и не факт, что пользователь их запросит. Тем более подгруженный не в том месте код может испортить форматирование. Если на сайте много всяких "закоулков", то преимущество такого подхода весьма сомнительное...
В таком случае надо эти специальные стили хранить отдельно и подгружать отдельно.

Уменьшения запросов на сервер с хотя бы пяти до одного — большой плюс.
Уменьшаем загрузку страницы? Звучит так, как будто с нее мешки с песком сбрасывают. Уменьшаем время загрузки страницы.
Есть замечательнейшая либа, сливающая и заодно сжимающая группу css или js файлов в один.
http://code.google.com/p/minify/
О чём заметка?
Такой огород нагородили :)
да, собственно, просто заявлена спорная тема. Сейчас комментарии гораздо интереснее самой статьи, хотя так и предполагалось :)
Надо развить тему, запихать этот скрипт в swf-ку 1x1 пиксель, воткнуть её по правильному через [object...] и пусть кто ни будь тогда скажет что у меня JS-a на странице дофига :D
Sign up to leave a comment.

Articles