CSS вообще не похож на «Максимум свободы». В нем нет многих элементарных вещей благодаря чему многие используют SASS\LESS\...\jQuery. А максимум свободы можно получить используя JavaScript (или, если нужно больше, то Assembler и т.д.).
Стоит отметить свое мнение относительно сабжа: товарищи из Apple пытаются заведомо запутать ситуацию, учитывая только целые device pixel ratio. Но с учетом префикса -webkit- это лучше чем отсутствие решений.
А мне полным решением данной проблемы видится такое:
Ввести новое семейство css свойтсв detalization ниже основные примеры.
min-image-detalization: 1px — означает что в 1px экрана должно загружаться не менее одного пикселя изображения.
max-image-detalization: 3dpi — означает что в 3px*devicePixelRatio не обязательно загружать не более одного пикселя изображения.
background-detalization: auto — устанавливается браузером и его настройками исходя из текущей скорости интернета.
detalization: best — всегда подгружать лучшую детализацию.
Научить браузеры, сервера и веб-мастеров по умному использовать прогрессивное сжатие jpeg и аналогов. Так чтобы браузер мог запросить у сервера только первую(первые) часть jpeg-файла, а за тем если необходимо — догружать остальное.
Использовать атрибут srcset=«image-l.gif 100X66 low; image-m.png 300x200; image-b.png 600x400 best» для форматов не поддерживающих прогрессивное сжатие.
Использовать background-image: srcset(url(image-l.gif) 100x66, url(image-b.png) best) для бекграундов не поддерживающих прогрессивное сжатие.
Но проще продвинуть нейроинтерфейс в котором отпадут подобные проблемы.
С этим приемущественно согласен. Но Вы предлагаете ввести в CSS возможности, которых ранее пытались избежать по причинам большой опасности для малоопытных верстальщиков.
Введение content:, вероятно, было принято в результате отсутствия других, достаточно удобных, вариантов. А в случае с srcset есть достаточно удобный(мне он кажется удобней вашего) вариант не противоречащий основным принципам взаимодействия CSS и HTML. Да и он обычно не подменяет исходные данные, а только дополняет оформление текстом.
В CSS вообще нельзя изменять аттрибуты HTML элементов (src — аттрибут). Ведъ CSS должен заниматься оформлением контента, и не затрагивать смысл (и структуру) контента. Иначе, например, была HTML страничка:
<html>Вот такой у нас рост прибыли: <img src="график.png"></html>
а после применения CSS стиля:
img { src: котики.jpg }
контент статьи о финансах будет испорчен. И это не правильно.
Для, например, ubuntu можно установить через
$ sudo add-apt-repository ppa:tuxpoldo/btsync
$ sudo apt-get update
$ sudo apt-get install btsync
при установке можно и пароль указать, и другие настройки. А на Raspbian Wheezy — пока тоько ручками. Могу заблуждаться.
Кстати, на iGoogle красовалась надпись «Служба iGoogle будет недоступна после 1 ноября 2012 г.»(по моей памяти). А теперь красуется надпись «Служба iGoogle будет недоступна после 1 ноября 2013 г.» и некоторые виджеты(например gmail) обновляются. Сдается мне, что google просто не будет активно развивать проект, хотя чего там развивать, но оставит работоспособным.
Конечно. Но в любом случае сайт в оффлайне запускать нужно из Application Cache. И для подключаемых .css, .js файлов использование Application Cache — более естественно. А непосредственно сам контент — без сомнения localStorage и изредка WebSQL.
Прочитал и понял: Вы собираетесь создать сайт, с хорошим доменным именем, красивым логотипом, оформлением. А основным контентом сайта будет текст манифеста. Если так, то лично я отношусь к этой затее скептически. По моему достаточно разместить такой манифест на той же википедии. И вместо этой затеи приложить свои силы к пропаганде манифеста на популярных площадках.
Да, кажется проверял это, но из за долгого кэширования гуглом моих лент — вывел для себя правило заменять подписку. А затем, вероятно, и причину своих действий забыл. Любопытно устроена человеческая память, с этаким кэшем, дающим сбои.
Я могу ошибиться, но для google reader настраивал свою RSS ленту только с хабами на которые подписан. Делал так:
1.Войдя на хабр под своим именем перешел в раздел лента
2.Смотрел в исходный код страницы в <header> должно быть примерно такой тег <link title="Захабренные / Посты / Хабралента" type="application/rss+xml" rel="alternate" href="http://habrahabr.ru/rss/feed/posts/e90e7f397a4956e66fb126dbacd4c29d/">
3. Вот этот habrahabr.ru/rss/feed/posts/e90e7f397a4956e66fb126dbacd4c29d/ и вставляется в google reader.
4. Если изменяем подписки на хабы, то операцию проделать заново, заменив старый адрес на новый.
Стоит отметить свое мнение относительно сабжа: товарищи из Apple пытаются заведомо запутать ситуацию, учитывая только целые device pixel ratio. Но с учетом префикса -webkit- это лучше чем отсутствие решений.
А мне полным решением данной проблемы видится такое:
Ввести новое семейство css свойтсв detalization ниже основные примеры.
min-image-detalization: 1px — означает что в 1px экрана должно загружаться не менее одного пикселя изображения.
max-image-detalization: 3dpi — означает что в 3px*devicePixelRatio не обязательно загружать не более одного пикселя изображения.
background-detalization: auto — устанавливается браузером и его настройками исходя из текущей скорости интернета.
detalization: best — всегда подгружать лучшую детализацию.
Научить браузеры, сервера и веб-мастеров по умному использовать прогрессивное сжатие jpeg и аналогов. Так чтобы браузер мог запросить у сервера только первую(первые) часть jpeg-файла, а за тем если необходимо — догружать остальное.
Использовать атрибут srcset=«image-l.gif 100X66 low; image-m.png 300x200; image-b.png 600x400 best» для форматов не поддерживающих прогрессивное сжатие.
Использовать background-image: srcset(url(image-l.gif) 100x66, url(image-b.png) best) для бекграундов не поддерживающих прогрессивное сжатие.
Но проще продвинуть нейроинтерфейс в котором отпадут подобные проблемы.
Введение content:, вероятно, было принято в результате отсутствия других, достаточно удобных, вариантов. А в случае с srcset есть достаточно удобный(мне он кажется удобней вашего) вариант не противоречащий основным принципам взаимодействия CSS и HTML. Да и он обычно не подменяет исходные данные, а только дополняет оформление текстом.
а после применения CSS стиля:
контент статьи о финансах будет испорчен. И это не правильно.
$ sudo add-apt-repository ppa:tuxpoldo/btsync
$ sudo apt-get update
$ sudo apt-get install btsync
при установке можно и пароль указать, и другие настройки. А на Raspbian Wheezy — пока тоько ручками. Могу заблуждаться.
И Chromium аналогично. А вот FF — капризничает.
Теперь с замиранием сердца жду ajax-ов на swapCache().
1.Войдя на хабр под своим именем перешел в раздел лента
2.Смотрел в исходный код страницы в
<header>должно быть примерно такой тег<link title="Захабренные / Посты / Хабралента" type="application/rss+xml" rel="alternate" href="http://habrahabr.ru/rss/feed/posts/e90e7f397a4956e66fb126dbacd4c29d/">3. Вот этот habrahabr.ru/rss/feed/posts/e90e7f397a4956e66fb126dbacd4c29d/ и вставляется в google reader.
4. Если изменяем подписки на хабы, то операцию проделать заново, заменив старый адрес на новый.