Пиксели это абсолютная величина. Проценты - относительная.
Если относительная - значит, относительно чего-то. % и em считают относительно родителя, rem относительно корня (html)
Сервис такой называется калькулятор.
У родителя размер 8px, у нужного элемента должно быть 14px, заданных через проценты. Считаем:
14/8 * 100 = 175%
Астрологи объявили неделю лендингов. Число топиков о лендингах увеличилось втрое.
Зачем для лендинга без обвязки джумла?
Steam, допустим, считает иначе. Я бы не рубил с плеча не зная конкрентой задачи и аудитории. Но если вы не знаете, стоит ли - послушайте SeVladа и не добавляйте видео (особенно, если у вас нет в планах покупки хорошего профессионального ролика).
А можно чуть более развернуто? Я всегда считал, что, скажем, 40 точек CDNa имеют более эффективное покрытие по сравнению с одной точкой ДЦ хостера. И намного веселее отдают медиа-трафик под нагрузкой в сравнении с шаредом.
С блекджеком и шлюхами :)
Кегельбан я, кстати, тоже никогда не писал. А вот браузерные игры приносили вполне сносный доход :)
Если не покупной сервис - это действительно интересно. Ограничив поддержку современным хроом, FF и (если повезет и оно умеет в современные стандарты) MS Edge, можно побаловаться с вот этим: http://www.webrtc.org/ . На связанных страницах можно увидеть упоминания тестовых браузеров (Chrome Cannary, etc), но лишь потому что эти страницы года на полтора устарели — сейчас хром поддерживает WebRTC из коробки.
Но если лендинг использует PHP - зачем запихивать эти значения в форму (где их можно подменить), и гонять туда-сюда? Их стоит читать по факту сабмита формы.
SeVlad имеет в виду, что на среднестатистическом лендинге самовоспроизводящегося видео быть не должно.
На практике это определяется несколькими факторами:
- никакой аудиодорожки (что для bg видео - дефолт, но лучше уточнить);
- целевая аудитория имеет быстрый интернет? Если да - оптимизируем порядок загрузки, чтобы видео грузилось после отрисовки страницы, и будет ок;
- смешанная целевая аудитория (в основном, мобильные) - делаем адаптивную верстку, мобильникам не показываем;
- видео не должно конфликтовать с контентом (например: http://thenewcode.com/samples/polina.html );
- имеет, если в стеке уже есть CMS;
- если нет CMS, и не планируется сколько-нибудь регулярно с ней работать — HTML;
- нет CMS, надо периодически менять контент и держать в порядке — генераторы статики (Jekyll, MiddleMan);
- оптимизировать ресурсы (корректные форматы изображений, спрайты для иконок, не лепить лишнего);
- оптимизировать порядок загрузки (кровь из носу надо влепить тяжелую картинку или видео - они должны грузиться _после_ контента. Контент должен корректно отображаться до их подгрузки);
- CDN. Например, у CloudFlare есть вполне сносный бесплатный режим;
Принято к исполнению :)
Похоже, уже и дополнительное. Но фору для самописных решений дать не грех.
Пока Арбит темнит и точит свой блокнот в ожидании вдохновения, а также пытается придумать пояснение, для чего он это делает, я отработал пару дней, покодил на досуге пару вещей, и даже нашел время для того чтобы записать в свой блокнот.
Я согласен, что задачка в стартовом посте - не предел интересности. И раз желающих на нее не нашлось — я с понедельника начну делать ToDo менеджер.
Почему? Эта задача интересна хотя бы одному человеку - мне. Она тоже не бог весть что, но дает упор на вещи, которые я знаю не слишком хорошо. Персонально для себя я также планирую использовать BDD, вместо просто тестов.
Если кому-то еще интересно — буду рад пилить параллельно. Если нет, значит нет.
Планируемое время — 23/11 … 7/12, т.е. две недели реального времени, в которые я ожидаю найти ≈40 часов времени на код. Планируемый результат — готовое к употреблению приложение (вместо среза функциональности за малое время, как предлагалось изначально).
Если шаред, то и на пол запроса может ругаться. Они на этом живут: продать 150% ресурсов сервака, а потом уломать на тариф подороже.
Если вдруг на серваке есть доступ к кешам в памяти (мемкеш, АРС, редис) - юзайте их чтобы всегда помнить эти две четверки. Если нет - внешние БД в помощь, МонгоЛаб, например, 500Мб монги дает даром - но добавится задержка на обращение к ней, соответственно.---------- Добавлено 20.11.2015 в 01:00 ----------Еще вариант: товары вы все равно выбираете. Как я понимаю, проблемы у вас начинаются на дополнительном запросе, который определяет вхождение в (4 старых или 4 новых). Эту информацию вы можете прицепить прямо к записи товара, и обновлять по добавлению/удалению товара.
Я изначально работал со скриптом товарища Kedr777, и, если не ошибаюсь, на нем такой проблемы нет.
Скрипты при этом несколько отличаются друг от друга. Я бы для начала внимательно пересмотрел внесенные правки - возможно, случайно зацепили лишнее.
