все зависят, повторяю,
от контекста, мой читатель,
вне контекста, к сожаленью,
не бывает ничего!
Абсолютно ничего,
кроме Бога одного. (с)
Но сплошь и рядом можно наблюдать когда разработчики отрываются от контекста и у них возникают проблемы которую вынес топик-стартер в заголовок.
Если юзер выбирает что-то из таблиц, вводит цену, поисковые слова и т.п. то вопрос об индексации снимается сам собой.
Верно. Я пропустил терки с js-фреймворками, потому что они не имеют абсолютно никакого отношения к заданной Вами теме.
пути прогресса извилисты и иногда идут через ж... Как в случае с #навигацией. Я не говрю что это плохо или хорошо, я говорю что Google своими протоколами вместо ясности внес дполнительные вопросы у тех кто не врубился в тему индексации динамических сайтов.
А кто у него броузера будет спрашивать, когда речь идет о js-приложениях? /ajax/url против /#url даже предпочтительнее в случае с маниаками которые выключают JS
Иногда - да. Иногда - нет. Все от разработчика зависит.
Даже если техология даст 100%-выигрыш, ее применение обусловлено кучей факторов, включая и индексацию поисковыми машинами.
Если разработчик не понимает механизм индексации динамических сайтов, а индексация нужна, то лучше бы ему за это не браться.
burunduk прав 100%, а вы - не совсем верное расставили акценты :)
Соотношение server-side / client-side диктуется исключительно задачей, которая стоит перед разработчиком. При этом использование Ajax совершенно не отменяет возможность полноценного индексирования всего чего нужно даже для тупых ботов, которые этот Ajax еще не понимают.
Никто ни раньше ни сейчас не мешал при наличии Ajax-контента давать нормальные (не хэш-) ссылки на страницы, содержащие этот контент.
т.е. вместо /url/#content вместо /url/ajax/content
Но поскольку кто-то завел моду на хэш, Google ввел специальные протоколы для этих ссылок. В результате вопросов стало еще больше.
1. Картинку можно редиректить через .htaccess
Псевдослучайность ввести используя число секунд , например в RewriteCond
http://www.askapache.com/htaccess/time_hour-rewritecond-time.html
2. SSI
Вы забыли что броузеров этих до фига и больше. Валидация конечно ничего не гарантирует, но риск напороться на кривое отображение снижает.
Вы сами привели фрагмент кода, который может отображаться по разному в разных броузерах:
1. Зависит от стандарта. в xHTML4 это ошибка. В некоторых старых версиях FF верстка ломались если внутри строчного элемента был вложен блочный. Пруфлинк. Но никто не гарантирует что в будущем броузеры правильно отработают ошибочный код.
2. На SEO это влияет. Потому что указывает что у верстальщика низкая квалификация и скорее всего страница весит больше чем нужно, а скорость загрузки (по утверждениям Google) влияет на результаты.
Странно, но у меня все как надо работает. ie7-ie10
вы бы дали ссылку, а то по огрызку CSS гадать сложно.
Я где-то написал, что кроссброузерность и валидность одно и то же? (а для ценителей еще есть замечательное слово "велформенность":)
Тогда можно договориться до того что сайт отображается верно и пофиг, что он всюду отображается но нигде не работает.
Разработчику не нужно, а заказчику вполне себе нормально. Вместо того чтобы ставить/обновлять лишние плагины и держать лишние броузеры, можно просто держать валидатор в закладке.
Зачем нужно заказчику я уже объяснил. Чтобы сократить расходы на поддержку сайта. В том числе на переверстку когда появится какой-нибудь новый броузер, который будет иначе "исправлять" баги верстки. Такое было много-много раз. И обязательно будет. Тем более что "реальности современности" вынуждают плевать на стандарт, который сам по себе не стандарт, а один большой баг.
Валидация верстки нужна для того чтобы быстро находить ошибки верстки допущенные при последующих изменениях дизайна и структуры сайта.
Если сложный сайт исходно сверстан с большим количеством ошибок, найти почему полетела верстка из-за незначительного вмешательства достаточно сложно.
Если верстальщик не будет сопровождать сайт, ему валидация нужна для сохранения кармы. Чтобы его потом не поминали недобрым словом.
А заказчику валидация нужна по-любому. Это сократит время и трудозатраты на сопровождение.
валидация/кроссброузерность. Тыщу раз проходили как нормально выглядящая в броузерах невалидная верстка разваливалась в новых броузерах. Особенно этим славилась покойная Опера, которая до 9-10 версии очень любила изображать из себя глючный валидатор. Т.е. валидация не гарантирует кроссброузерности, но невалидная верстка потенциально опасна для кроссброузернгости, потому что в стандарте не предусмотрены исключения.
