Shift-Web

И скорее бы ИЕ7 тоже перестали пользоваться, то удачно забыла бы страшное слово - layout. Доооо! Это мечта Откуда у тебя такой смайлик? В моем стандартном наборе нету такого. Фокус-покус. Right click => copy image url => insert image => past image url => submit

Читал это и ещё многое. А вы какой подход видите более рациональным?

Нормальный пай

И скорее бы ИЕ7 тоже перестали пользоваться, то удачно забыла бы страшное слово - layout. Доооо! Это мечта

Yo!

Господа, возникает немного стрёмный вопрос. Сайты, которые я делал раньше, можно сказать топром и кувалдой, не особо задумываясь о красоте кода и прочего на данный момент довольно красиво работают. В последнее время я стараюсь уделять внимание таким вещам, как рациональность, красота, удобство работы и прочее, не забывая о производительности. Так вот, странное наблюдение. Код подтормаживает и это видно не особо вооружённым глазом. Собственно хотелось бы поговорить на тему быстрого CSS и HTML. Наверняка у каждого есть свои привычки и какие-то идолы, было бы очень здорово пообщаться на эту тему и поделиться какими-то своими заморочками ) В последнее время мне нравится подход на импортах, когда подразумевает растаскиваение стилевых групп в большей степени не по общим признакам совпадения(хотя и это тоже), но по признаку функциональности. Если речь идёт о каких то просты вещах, то всё просто и офигенно, но когда сайт довольно кудряв и сложен такой подход вызывает некоторую избыточность и по всей видимости может являться причиной неявных тормозов. Встречается множество литературы на тему оптимизации селекторов и выборок, но в большинстве своём, материал оказывается применимым очень местно и, на мой взгляд, не совсем употребим. Кто-то нашёл золотую середину, как писать в балансе? Дело в том, что спрос на CSS3 довольно динамически растёт, но т.к. технология сыровата имеют место вопросы в роде быть или не быть и если быть то в каком виде. Вот пожалуй парочка вопросов, которые самостоятельно у меня выявить не получилось. Влияет ли явно на производительность перегруппировка селекторов в пользу обращений через id или скажем в пользу отновительно современных CSS2? Так ли критична тотальная перегуппировка по половым(употребления одинаковых каскадов) признакам? Как на ваш взгляд влияет наследование на производительность? Ну и вообще, кто как считает надо писать? ) Спасибо

Дело не в картинке. Картинки не вызывают залипот, они я так понимаю просто лежат в памяти сплошным слоем, а вот обилие всяких элементов до кучи интерактиных, вызывает постоянный пересчёт рендера, что в итоге выливает в слады и тормоза. Беда в общем

Благодрачик. Вот кстати, с релэйшнами несколько неясно, что будет. rel="archives" -- парсер жрёт только при наличии xmlnamespace.

Сейчас всё более-менее. Написал пресчёт скорости в зависимости от пути, но некоторые штуки пришлось выломать. Тормозит в основном на ПК типа ноутбука. Большой брат скролит довольно хорошо, но ведь не у всех современное оборудование. В общем-то тут всё сложнее оказалось. Очереди анимации не спасают фактически, а при одноврмененном выполнении 2 и более эффектов вместе со скролингом браузеры вроде FF, Opera и IE просто захлёбываеются. В общем, сделал всё проще.

Метод неистово тормозит на FireFox, Opera и приводит покадровке на IE. Ситуацию усугубляет 3й CSS, коего достаточно обильно и коий без всяких анимаций вызывает неистовый батхер у IE9. Вариантов вижу несколько: а). обыграть встроенный метод отдельной функцией(сомнительно, что может помочь) б). сделать что-то вроде плавного старта и плавного стопа, дабы позволить браузеру отрендерить всё более гладко в). забить и выпилить скролл г). поискать какой-то адекватный плагин Есть ли сопособы изящного решения данной проблемы без хардкорных навесок?

Убедили.

А с точки зрения этого outline, т.е. по прямому назначению, секция равносильна "куску от заголовка включительно до следующего заголовка исключительно". Философский вопрос, конечно, а нужна ли она тогда вообще...) И это значит, что я не могу сделать скажем 2 секции? В одной структура с основным каркасом и содержимым, в другой ещё что-то косвенно относящееся к сайту. На счёт того, нужна она или нет - соглашусь. Бесполезный тег, и длинный.

>> Поисковик анализирует не строение сайта, а контент. Зачем ему знать где у вас хедер, снизу или сверху?) А как ему узнать, что это хэдер блока, в котром может быть заголовок и этот хэдер описывает то, что находится в обособленном контейнере? Как он поймёт, что содержимое в обособленном контейнере имеет некоторую логику, которую до кучи, как обозначили выше, может использовать не только поисковик, но и любое другое интеллектуальное устройство. Завтра айфоны отсохнут или мутируют в контактную линзу, управляюемую лучами добра или зла, исходящими от ваших мыслительных флюид(образно). Тем более, по некоторым заявлениям, HTML6 не будет. Всё это планируется, как долгосрочная модель, на которую фичи будут постепенно навешиваться. А что, например, с данными? Это тоже очень удобно эффективно. Гораздо проще сделать стандарт и, если ему последуют, подкрутить парсеры, нежели делать дубовые алгоритмы, которые ещё очень долго будут дубовыми(в отношении SEO). Эт давно уже реализовано на самом деле на серьёзных проектах. Просто "мы" в танке, или не хотим. Это просто неправильно: <section> не обёртка. Этот элемент означает семантический блок Вашего контента, использующийся для построения «структуры документа» (document outline), и должен содержать заголовок. Если Вам нужен элемент для обёртки, попробуйте обойтись <body> (Kroc Camen может предложить кое-что). Если это не решает проблему необходимости дополнительных обёрток, используйте старые добрые <div>'ы. С приходом HTML5 <div>'ы не умерли, и именно они отлично подходят в этом случае. Хрень какая-то. А что же это ещё? Любой элемент, кроме пустышек и мет, это есть обёртка. Где хоть в одном авторитетном месте написано, что я не могу сделать так?

Rapid PHP 2011. Очень понравился Хороший софт

Присоединяюсь к поздравлениям

Ждите кейфрэймы для остальных браузеров, наверняка опера и фокс скоро подтянутся. Экстра-разметка не есть гуд

Начну понемногу, через месяцок закончу, наверное.

Боюсь что да... Да это понятно, что я не владелец Apple и чего супер крутого внедрить навряд ли смогу, по крайней мере в ближайшее время. Просто интересно понять алгоритм всего этого тусища и рождения каких-то новшеств. Просто как бы курить всё подряд смысла маловато. А так, можно было бы, скажем, прогнозировать эффективность и востребованность того или иного решения.

Я не об этом. просто есть подозрение, что этот короткий хвостик вырастет в отдельное семейство языков и спецификаций. А трудно свою спецификацию протолкнуть? Я вот смотрю что всё рождается силами "сторонних людей", заинтересованных в каких то фишках и примочках, а в последующем дотачивается и выносится на пережёвывание. (Это так, просто мысли. пытаюсь понять как эта вся шняга крутится).

Офигентос! Но этокстра разметка не есть гуд. Пробуйте ::after и ::before

Судя по всему. Короткому доктайп конец. To avoid the issues of named character entity support and quirks mode, authors can instead use the following generic DOCTYPE declaration for HTML: <!DOCTYPE html> However, this still does not guarantee that documents will be validated by conformance checkers. —-- Халява кончилась, не успевши начаться

Как знаете. Я лишь высказал своё скромное мнение.

Для изучения хороши любые оригинальные внутренности. разглядывание чужого кода -- это достаточно увлекательный процесс, который помогает улучшить свои навыки и подтянуть какие-то приёмы. Нативный код -- это код работающий без дополнительных навесок и ухищрений вроде jQuery и пр. Со стороны серверной части нативным не будет использование API какой либо системы или библиотеки. Нативность означает скорее оригинальную разработку не требующую дополнительных компонентов. То, что вы заявили, как научиться пользоваться canvas и связанным с ним нативным API несколько не вписывается в концепцию конкурса. Противоречие. Вы предлагаете поупражняться не в применении конкретно canvas, а в реализации более менее серьёзного приложения, сознательно ограничивая возможности участников. Имхо. И, как можно заметить, API canvas -- это 5% всего приложения, в лучшем случае. В худшем, ещё меньше. Основная логика будет написана исключительно отдельно. сабж

И что теперь? Там есть чему поучиться и используется, кстати, нативный код. Те же внутренности библиотек могут быть весьма полезны.

фэйл.... проще, ещё проще