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 ещё год-полтора будет актуален ?)

например так + min-width: 1280px по контентному врапперу так же css parallax scrolling можете посмотреть (для сложных меняющихся бэкграундов при изменении размеров окна)

таки стыкуются. первые три ссылки в СЕРПе по тем ключам http://www.alistapart.com/articles/slidingdoors/ http://www.dynamicdrive.com/style/csslibrary/item/sliding-doors-tabs-menu/ http://kailoon.com/css-sliding-door-using-only-1-image/

buddah, не, пробовал тоже, эт не помогает, вообще все бэкграунд-баги при отрицательных маргинах в ИЕ6 лечатся в основном position: relative, но у меня и так все столбцы относительно спозиционированны psywalker, спасибо! это кажется одна из вариаций http://www.alistapart.com/articles/negativemargins/ , но тут проблема не в сверстать 3х колоночную резину по контентному столбцу, а просто разобраться в природе этого бага и способах его фикса ) Vlad, угу, спасибо, но этот случай, как я понял, вообще для бэкграунда заданного любым способом, а в моём случае, баг проявляется, если в качестве бэкгрануда используется изображение (когда он задан просто цветом, то всё ок: 1й скрин - это в ИЕ6, когда бэкграунд задан цветом, 2й - когда картинкой)

приветствую, понадобилось тут сверстать макет, обычный трёхколоночный макет (в данном случае классический Holy Grail) с колонками одинаковой высоты и резиной в столбце контента, при компановке колонок по схеме 2-1-3 (контент - 2я колонка, идёт в коде первой, сайдбары - после неё, но потом позиционируются и т.д.). Всё разумеется отлично работает в браузерах, кроме IE6 (IE 7 рендерит правильно), для которого я сам так и не смог подобрать хака самостоятельно. Исходник для повторения (copy-paste ready): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Untitled Document</title> <style> * {border: none; outline: none; margin: 0; padding: 0;} body {font: normal normal 10px/1.6 Verdana; position: relative; height: 100%;} .layout-wrap {padding: 0 20em 0 25em; overflow: auto; min-width: 40em; background: #90F; height: 100%;} .fake-wrap {float: left; position: relative; width: 100%;} .column {float: left; position: relative; width: 100%;} /* holy grail columns */ .aside-wrap {left: 20em; margin-right: -20em;} .nav-wrap {margin-left: -100%; left: -20em;} .content-wrap {left: 100%;} /* columns content positioning */ .second-nav {width: 25em; margin-left: -100%; right: 25em;} .aside {width: 20em; margin-right: -100%;} ul {list-style: none;} .column p, .column a {font: normal normal 1.4em Verdana;} /* debug colors */ .aside-wrap {background: green; } .nav-wrap {background: red;} .content-wrap {background: yellow;} /* Этот самый баг ИЕ6 */ .nav-wrap {background-image: url(gnd1.jpg); } </style> </head> <body> <div class="layout-wrap"> <div class="fake-wrap aside-wrap"> <div class="fake-wrap nav-wrap"> <div class="fake-wrap content-wrap"> <div class="column content"><p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc non diam at nisi mollis aliquet. Sed et risus leo, a aliquet orci. Donec hendrerit fermentum sagittis. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; In fermentum tortor et tortor lacinia fringilla. Ut et est at sapien dignissim hendrerit ut ut ipsum. Vestibulum convallis posuere metus in sagittis. Nunc aliquet est elit. Donec id lacus odio, ut ultricies felis. Ut congue tristique mauris, at sodales sapien cursus et.</p> </div> <div class="column second-nav"> <h3>Widget Name</h3> <ul> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> </ul> </div> <div class="column aside"> <h3>Widget Name</h3> <ul> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> <li><a href="#" title="">Widget item name</a></li> </ul> </div> </div> </div><!-- end .inner-fake-wrap --> </div><!-- end .outer-fake-wrap --> </div> </body> </html> баг заключается в том, что если первой спозиционарованной колонке (в данном случае, это столбец с классом nav-wrap ) в качестве бэкграунда задать любую картинку, (здесь это .nav-wrap {background-image: url(gnd1.jpg);} но баг возникает и даже если это просто прозрачный однопиксельный .gif), то эта первая колонка теряет свои координаты, полученные при позиционировании, или что-то в роде этого, то есть, визуально это представлено на скринах: 1. в качестве бэкграунда для неё задан просто цвет .nav-wrap {background: red;} 2. в качестве бэкграунда задана картинка background-image: url(gnd1.jpg); во всех других браузерах (и почти браузерах) это должно выглядеть как-то так: собственно, подскажите как можно это дело профиксить (актуально только для ИЕ6) Спасибо.

нормальные верстальщики есть, по крайней мере один - Вы ) а по сабжу, гуглите CSS sliding doors/css clipped sliding doors (во втором по-сути используются прозрачные .png и маргины для списков)

ясно, спасибо, в общем жесть оказывается... осталось только решиь для себя чем можно поступиться - вернуться к таблицам или смириться с несемантичными обёртками

Приветствую, не могу победить особенность некоторых браузеров при вычислении суммарной ширины сестринских float-ов, в случае задания ширины родительского контейнера в процентах. Например: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Untitled Document</title> <style> * {margin: 0; padding: 0; border: none; outline: none;} #wrap {width: 60%; margin: 0 auto; background: #F3F; overflow: hidden;} #nav {float: left; width: 100%; background: #039;} #content { float: left; width: 100%; } #col1 { width: 30%; background: #999; } #col2 { width:40%; background: #696; } #col3 { width:30%; background: #0CF; } #content div {float: left; clear: right;} </style> </head> <body> <div id="wrap"> <div id="nav"><p>NAV</p></div> <div id="content"> <div id="col1"><p>Column 1</p></div> <div id="col2"><p>Column 2</p></div> <div id="col3"><p>Column 3</p></div> </div> </div> </body> </html> Здесь, #wrap - главный родительский контейнер, который задаёт общую ширину в процентах, относительно которого уже и высчитываются все вложенные значения ширины, сабжевая проблема наглядно продемонстрированна на следующем скрине: Здесь, справа от Column 3 видно малиновой фон внешнего контейнера (#wrap : ... background: #F3F;...) чего не должно быть, так как ширина предка для плавающих элементов col1-col3 задана в 100%, а их ширины (col1-col3) в сумме составляют 100%. вот здесь, этот участок увеличен для большей наглядности: Собственно, почему это происходит и как решить проблему кроссбраузерно ? зы: "малиновая полоса" появляется в Opera (всех версий) и во всех webkit (то есть safari & chrom), отсутствует в IE8-9 и ФФ (> 3.6 версии, ниже у меня нет). Так же, эта особенность не проявляется в IE6-7, но там свои особенности и непроявляется она из-за другого бага, который фиксится clear: right и затрагивает другие особенности, но эти два браузера мы в расчёт не берём. Спасибо!