s0rr0w

Я тебя умоляю... Буратины везде найдут способ создать другим проблемы...

Так это потому что в CSS до сих пор ( ) нет ни одного намека на поведение элемента. Если бы появилось, то я бы послал HTML к чертовой бабушке и забыл бы как страшный сон!

Беда в том, что при таком молчаливом поведении парсера никто не узнает про тот факт, что так делать нельзя. Вернее многие начнут думать, что так делать можно, ведь браузер что-то отображает, значит этот код правильный. В спецификации написано что можно, значит можно. Но лучше стремиться к порядку в голове и коде и все же закрывать все теги.

Что, можно уже писать вот так? <img src="test.png">Буууу</img>

Иногда нужно добиваться максимальной скорости работы, и регулярки могут оказаться самым быстрым способом. В собственном коде нет никаких проблем. Ты сам себе отдаешь отчет, достаточно ли такой гибкости или нет в данном случае. Проблемы возникают только на момент кроссистемного взаимодействия. В том то и дело, что если написать парсер по стандартам, то любая "кривая" страница становится невалидной и парсинг нужно останавливать. Это существенно ухудшает результативность работы некой программы, и требуются дополнительные ресурсы на предварительную нормализацию исходного кода. А так как парсеры разрешают расслаблять батоны и чудить в коде, результат не заставляет себя ждать: количество неправильных страниц множится как грибы после дождя. Вольности приводят к накладным расходам и делают в целом только хуже. Для всех.

Серверные скрипты. Получил исходник чужой страницы. Нужно вырезать только текст новости, без оформления. Если из доступных средств только regexp, то найти окончание контента без закрывающих тегов становится мучительно больно. Возможно, но гораздо труднее. Некоторые XML-парсеры (не умеющие или не подозревающие про HTML), никогда не построят нормальную DOM-структуру, и придется вручную закрывать теги. Обходится предварительной нормализацией контента при помощи того же tidy, но и эта утилита не всемогуща.

Для результатов поиска товара в инет-магазине сразу сделать меню "добавить для сравнения". Контекстное меню позволяет не загромождать данные управляющими элементами не первой важности

Зеленый нужно сделать темнее чуток, или десатурировать слегка, чтобы он был одинаковый по серой составляющей. Про что я веду речь? Преврати рисунок в Greyscale, посмотри как отличаются цвета по интенсивности в градациях серого.

Я уже понял, что нужно сделать. Есть у меня один могильничек примерчик, который может заинтересовать многих... Для меня многие вещи очевидны, для того, кто пытается изучать это не так. Спасибо что вернули на землю Самое смешное, я не советую SC для обычных сайтов. Там более выгодно применять jQuery. Недавно делал один сайтец (наверное, последний в моей жизни), так вот на фронтенде я использовал jQ, а для бэкенда - SC. Каждому инструменту свое собственное место применения.

По сравнению с другими компаниями. Очевидно же. Не вижу смысла называть название своей компании. Это бесполезная для вас информация. Кривые руки никто не отменял.

Ха, так у тебя вопрос неправильно задан. Все общение должно свестить к следующим вопросам: 1. Какой из "ушей" должен иметь больший акцент? Синий имеет выше контраст и даже маленькое по объему синее цветовое пятно перевешивает более светлое, пусть и большее по размеру, зеленое цветовое пятно. 2. Правильно ли расставлены "уши"? Привычка человека читать с верхнего левого угла в правый нижний, поэтому данные на синем "ухе" попадают по пути следования глаз, а зеленое "ухо" менее привлекательно для чтения данных. Про это надо помнить, и расставлять акценты по важности содержимого ушей. 3. Зачем вообще делать двойные "уши"? Это концентрирует в одном месте слишком много управляющих элементов, и часть информации может просто теряться на фоне контрастов. Быть может, стоит применить другие дизайнерские приемы и разнести пункты в стороны, дабы не вызывать перегрузку мозга пользователя...

Конечно же чушь! Особенно показательная "чушь" была на Хабре, когда количество комментариев становилось огромным, браузер с трудом ворочал весь этот список. Особенно на слабых компах. Даже на Хроме. И на Опере тоже. Продолжайте пользоваться jQuery и свято верить, что именно эта библиотека решит все ваши проблемы настоящего и будущего. Лично мне пофиг, будете вы что-то новое учить или нет. Мне даже выгоднее, чтобы было больше низкоквалифицированного персонала на рынке, ведь это делает мою компанию еще более конкурентноспособной.

Прототайп используется гораздо чаще в веб-приложениях. Мутулсы аналогичны jQuery, тот же подход в работе. Ext.js для любителей геморроя. Шаг влево, шаг вправо - нестерпимая бесконечная боль. Я пошуршал по соцсетям, посмотрел в Google+, Facebook, там jQuery и не пахнет даже.

Это конструктор. Хочешь - собери гармошку, хочешь - пароплан. Все упирается в написание обработчиков. Сейчас подумываю сделать пример интерфейса с готовыми решениями, чтобы было интереснее исследовать код. Беря готовое решение разработчик обрекает себя на непонимание многих принципов, хотя и сокращает себе время первичной работы. Устоявшиеся паттерны могут быть ошибочными. Они как раз и приводят к часто распространенным ошибкам. Весь код jQuery вращается вокруг двух точек опоры: навешивании обработчиков на элементы по событию загрузки документа, и поиске элементов для работы. С одной стороны все выглядит вполне логично и понятно. Но как только потребовалось подгружать html автоматически на страницу, сразу потребовалось переписывать код jq, добавляя live-события. Что это значит для кодера? Что нужно еще больше следить за количеством элементов, которые выбираются в селекторах, иначе через время все будет еле-еле ворочаться. Кеширование сделать не получится ну вообще никак, это значит, что с ростом сложности селекторов и количестве функций, тормоза будут только расти. Паттерны, которые используются в SC - куда более распространены, чем те, которые используются в jq, потому что там используется событийная модель. jQuery в проекте даже не было, а событийная модель уже была. Самое смешное, но модель аналогичную SC можно построить и на jq, но это будет в пару раз медленнее. P.S. И я на критику не обижаюсь, потому что понимаю причины ее возникновения.

Очень сильно похоже на проблему записи в темповую директорию. Данные, которые ты аплоадишь на сервер, должны складываться в некую временную папку, потом скрипт их забирает оттуда и уже с ними работает: либо загружает в базу, либо раскладывает по другим папкам. Во втором случае, он может и загрузить файл на сервер, но у него не получится его подложить в нужное место из-за проблем с записью. Почитай php-логи апача, может там будет больше информации.

Кто сказал, что я не люблю jQuery? Я просто без щенячьего восторга отношусь к данной библиотеке, понимая все позитивные и негативные стороны. Непонятное только первые 10 строчек кода. Как и любая новая библиотека. Мне трудно пояснять преимущества подхода людям, которые не хотят понимать эти самые преимущества. Но я не настаиваю. Плохо тем, что jq постоянно мутирует и видоизменяется. Это главный негатив данной библиотеки. И переделкам нет конца и края. В отличие от SC, в код которого я не лажу уже более года точно, и то, по причине ненавязчивого расширения, на остальной код это никак не повлияло. А теперь представьте, сколько версий jq нужно хранить в браузерах, чтобы все сайты работали. Ответ - все версии. И кто от этого выиграет? А никто.

Веб-студия делает сайты. Веб-девелоперские конторы делают программные продукты на основе веб-технологий. Иногда веб-студии делают программы, но это скорее исключение, чем норма. Может кто-то и использует SC, не знаю... Мне все равно. Используют - хорошо, не используют - тоже хорошо, так как у меня появляется конкурентное преимущество. SC применим в сложных проектах, где важным становится не писать меньше буковок, а вообще как можно меньше писать. Основные проблемы в разработке программного обеспечения заключаются не в том, чтобы быстро что-то написать, а в том, как просто это будет потом поддерживать, изменять, как быстро там можно будет найти ошибки и так далее. Т.е. важны не только первичные вложения времени, но и каждые последующие. SC создавался как раз с учетом этих требований: легкость последующих модификаций кода, а не низкий порог вхождения и мало написанных букв. Это другой мир, он мало понятен простому кодеру, который делает сайты-визитки. XML не куда развивать, это самодостаточная технология уже с момента ее написания. Браузеры поддерживают, но как всегда совсем отличился IE. Сейчас, начиная с 9-ки, все намного лучше, но проблемы есть у всех, и у Оперы, и у Хрома. XSLT есть куда развиваться, но ни у кого нет желания писать парсеры, неблагодарное это дело. Поддерживается самая простая версия - первая. Вторую не все языки программирования то поддерживают. Но технология полезная однозначно.

Среди веб-студий не актуален. Актуален среди веб-девелоперских контор. Технология не распространена, поэтому пользуйтесь и дальше jQuery

А нет смысла что-то добавлять, код и так достиг максимума. Далее только будет только задротсво.

Я использую SC. Исключительно Конечно же жив. Переносится на следующие проекты. И, что меня не может не радовать, не требует к себе внимания и не переписывается уже более года. Идеальная библиотека с точки зрения промышленного использования. Да, для простых сайтов jQ предпочтительнее. Но в интерфейсах и веб-продуктах это будет гиря на ногу.

Не работает.

А я за хирурга, который безболезненно эти руки отрежет и перенесет их в другое место. В своих проектах я обхожусь без jq. Вообще. Короткий код не синонимы быстрой разработки или хорошей масштабируемости. А коммерчески выгодно не меньше символов писать, а меньше раз писать эти самые символы.

Лучше всего оформить его как сайт-поздравление.

JS не имеет доступа к HTTP-заголовкам.

А я сказал, что еще не раз за ней придете. Ведь тема сложная, за один раз не выучишь все.