alb

если верить разрабам мускула, планировщик прекрасно справляется с order by rand() в сабжевом случае, но адский ад однозначно будет, в случае order by rand() limit x,y. В общем, всё зависит от задачи - если подобных операций много, то имеет смысл ввести отдельную вспомогательную таблицу соответствий первичных ключей оригинальной таблицы и порядковых номеров строго по возрастанию без дырок в последовательности (то есть 1,2,3,4,...,x но не автоинкремент, так как появятся дырки при удалении), затем, если нужно получить какое-то кол-во случайных строк, сперва просто генерим случайные цифры от 1 до %количество_записей% в вспомогательной таблице, затем, смотрим какие ключи соответствуют этим номерам в основной таблице и селектим их обычным предикатом in (). В этом методе, важно не допускать дырок, которые могут появиться при удалении строк, но это всё просто решается триггерами и перестановкой индексов. Метод требует одну дополнительную таблицу для каждой основной таблице по которой часто предполагается делать рандомные выборки, но полностью оправдывает себя в хай-лоад проектах, за счёт линейного количества выборок (кол-во выборок * 2) при любом кол-ве записей.

в принципе, во всех случаях, когда позволяет версия сервера СУБД, юзаю курсор в хранимке... делать это в клиенте (ПХП), имхо лишнее

сабж старый, но апнуть считаю обоснованным, потому как для этого есть специальная ф-ция, о которой не все догадываются кстати, COUNT(*) в качестве знаменателя, то же не правильно, так как звёздочка вернёт все записи, значения `price` столбцов которые могут быть и null, тогда уже использовать `any`... но лучше всего, разумеется соблюдать "семантику", и юзать avg()

крутись в самый конец страницы, там есть фотка коленного сустава, маркерами выведены номера, а справа - названия. Подводишь мышку к номеру на картинке, и справа подсвечивается название. Кстати, другой пример - описание к фоткам вконтакте - наводишь мышку на кого-то и за пределами фотки появляется имя этого человека. Это так же ещё называется CSS ImageMaps (но правильнее именно css remote rollover, как назвал этот способ автор, в первые предложивший использовать для этого чистый ЦСС и абсолютное позиционирование). То есть, если говорить в привязке к сабжу, то определние перса я бы делал именно через css remote rollover, и передавал бы на сервер сериализованную форму с дополнительными полями, одним из которых бы было название (id) перса, выбранного кликом по css rollover картинки. кстати, вот более вменяемый пример http://www.cssplay.co.uk/menu/imap.html этого как оно называется по-русски, сорь не знаю, так как переведённые мануалы не читаю в принципе

ну например физически одна кнопка в виде изображения Ваш пол: "Мальчик|Девочка". Здесь "Мальчик" и "Девочка" занимают 50% кнопки, и зная общую её ширину, мы можем определить пол. Так же, например, выбор ну... скажем "перса" в какой-то браузерке: групповая картинка Эльфа, Гнома, Хоббита и т.д. и при сабмите можем получить какого перса выбрал игрок, имея только одну кнопку. в действительности, например эту часть, я бы делал этот выбор например css remote rollovers-ами, и при выборе каждого пункта формы, собирал бы её данные для отправки аяксом. то есть я про то, что type="image" - это скорее наследие old plain html, и не выпиляли его только из-за того, что позволяет передать координаты клика при сабмите, то есть, нужна в исключительно в специфических приложениях, а все кнопки, которые используют картинку и по своему назначению являются только сабмит-кнопками, я бы всё-таки использовал type="submit"

ну так а в чём проблема то?) верстка двухколоночных макетов верстка трехколоночных макетов

уу, эт чё за разработчики такие ?) О том, что форма отправлена, следует судить по методу клиентского запроса, в случае же аяксовой отправки, например get-ом, о факте отправке нам говорят именно эти самые аякс х-заголовки. И это важно, так как если мы будем писать какой-то CMF, то при составлении маршрутов раутинга, ни в коем случае нельзя привязываться к каким-то именованиям клиентской стороны, то есть именам кнопок, делая это, мы нарушаем основные принципы MVC вообще, а в случае веб-интерфейсов, ещё и устанавляваем жёсткую связь между въюхой и бизнес-логикой. ну а <input type="image"> - это скорее-всего прежитки старого веба, когда и стили то особо никто не пользовал, но украшательства кнопкам сабмита всё-таки были нужны, поэтому и ввели. Что семантичнее использовать для сабмита при просто отправки формы, когда кнопка сабмита задана картинкой? Имхо, всё-таки <input type="submit">, а type="image", только когда нужно подобие image maps-ов при сабмите.

не, ну тебе виднее канешна )

а где здесь собственно проблема вёрстки то?)

семантика CSS, это уже извините др*ство... давайте посмотрим сколько можно найти несемантических правил в среднем файле стилей, и я не думаю, что замена float-ов на inline-block сильно скрасит картину, зато, с другой стороны, у флоатов имеются и свои преимущества, например отрицательные маргины для флоатов, отсутствие влияния на поток (не обязательно ж это колонки могут быть) и т.д. Думаю, что флоаты нельзя выкидывать в качестве контейнерных блоков для создания колоночных разметок. Кроме того, каково семантическое значение display: inline-block, можно ли о нём сказать, как о средстве для создания тех самых колонок?) В случае же например, с вёрсткой галереи (ряд тумб), там display: inline-block даже очень семантически оправданы, но перекладывать на это сво-во все прочие "обязанности" флоатов, кроме обтекания слева/справа, тоже не правильно (ту да же относится и ситуация с позиционированием) ИМХО, не стоит замарачиватсья, флоаты рулят и не только, как задание обтекания

у меня чёт Др. Вебер на http://ekimoff.ru/download/makets/makets.rar ругается... можно качать ?)

угу, но здесь всё зависит от пожеланий заказчика ) если вы верстаете какой-то сугубо коммерческий проект направленный исключительно на монетизацию, то ни о каких отказах от IE 6-7, к сожалению, речи быть не может, так как основная задача такого проекта далеко не валидная семантическая вёрстка. Лично мне приходится поддерживать ИЕ6, но делать это, как сказал vlad - "изящная деградация", то есть отсутствие попиксельной идентичности макету или рендеру в ИЕ6 и в новых браузерах, имхо, это самый правильный способ поддержки старых браузеров, разумеется, когда заказчик не против. А вообще, вот "официальная" статистика использования ИЕ6 в мире: ie6 countdown, где видно, что основная масса юзеров осла - это в основном Китай, Въетнам, Индия и Южная Корея, и если делаем сугубо под ру-сегмент, то полной идентичностью отображения в ИЕ6 можно пренебречь тем более.

угу, скорее-всего, что это то, о чём писали buddah и Vlad, что бы посмотреть, что у вас происходит локально, рекомендую посмотреть какие заголовки в запросах/ответах при получении этих картинок (F12 в IE9)

угу, имхо ради ИЕ громоздить вложенные элементы только ради создания тени, ни разу не правильно (кроме того, это лишние ноды в DOM), и лично я всегда для неполноценных использую любые возможные скрипты, что бы из-за ИЕ семейства не страдала семантика (разумеется, на сколько это вообще возможно для кроссбраузерных решений). В данном случае, думаю будет достаточно css3pie

имхо, по крайней мере пока он draft, никакого именно перехода на него не будет... какой html5, когда IE6 ещё год-полтора будет актуален ?)