Мифы веб разработчиков

[Ялекс]

Кстати, это пример очередного идиотзма. Ну какая индексация у картинки с загругленными уголками блока?

Закругления и все что относиться к дизайну выноситься в CSS. Контентные рисунки - <img>.

Так дисциплинирует W3C. И я считаю это правильным.

Вы можете оставаться при своём мнении. Не хочу завязывать спор, потому что, я предчувствую, что он будет глупым.

Edited January 3, 2009 by Ялекс

[homm]

Закругления и все что относиться к дизайну выноситься в CSS. Контентные рисунки - <img>.

Ах, это… Это просто неудачный пример. Ты же понимаешь что в дизайне все равно может быть полно элементов которые проще сделать в виде img. И для них alt не нужен. Но стандарты писались когда документы были уровня упомянутого wordpad и там да, было сложно представить картинку без альта.

[Ялекс]

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

[homm]

Ялекс, не согласие следовать правилам w3c не означает намеренное саботирование и делание «от противного». Я разве где-то сказал что альты не нужны? Я сказал что обязательное требование их ставить — идиотизм. Я показал на вскидку 3 примера, когда неследование этим правилам упрощает жизнь. При этом никто не говорит, что не нужно отделять представление от содержания. И отказываться от списка в меню я не призываю. Просто если можешь что-то сделать лучше и эффективнее, но тебя останавливает потенциальная невалидность — наплюй на нее, она никому не нужна.

[Ялекс]

Если плевать на валидность и делать все под браузеры, то инет никогда не выберется из огромной мусорки. Лучше идти на встречу прогрессу.

Валидатор - это круто.

В конечном счете хуже от него никому не будет. Только польза. Поэтому это очень хорошо, чту у вас есть Бог под названием Validator W3C!

Edited January 3, 2009 by Ялекс

[rash]

Господа, как-то многовато шуму вокруг валидатора...

Пошумлю, пожалуй, и я :-)

Валидатор - не судья. "Приговор: невалидно".

Валидатор - инструмент, советчик. "Посмотри, может быть тут у тебя ошибочка закралась..."

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

[Ялекс]

rash, да, хороший компромис.

Вот еще миф: сайты во flash - это круто.

Если поразмышлять, то флеш никак не может быть пропарсен. Информация скрыта от машин. Да и скорость загрузки не всегда быстрая.

Поэтому лучше не делать контентных сайтов на флеше.

Edited January 4, 2009 by Ялекс

[SelenIT]

Мда уж, страсти по валидатору разгорелись нешуточные .

Но насчет блочных элементов в <a>, по моему мнению, это не блажь валидатора/W3C, а очень полезный совет по избеганию граблей - от мелких визуальных типа таких до полностью нерабочей ссылки (вполне может получиться в том же IE, непример, при вложении таблицы в ссылку). Фокус в том, что в не предусмотренных спецификацией случаях браузеры строят DOM как им удобнее (как бы "исправляют битую разметку"), и никто не вправе их за это упрекнуть...

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

Вот насчет кастомных атрибутов для элементов форм - не спорю, удобно. Кстати, многое из подобного (упомянутый required, широко поддерживаемый браузерами autocomplete и т.п.) проходит валидацию как HTML5.

Edited January 4, 2009 by SelenIT

[Виртуал]

Но насчет блочных элементов в <a>

Если прочесть что я написал, можно заметить что я говорил об блочных элементах в блочном элементе <a>.

ради "гламурного" поведения

Ну ты сам придумал это слово.

[pyJee]

блочном элементе <a>

"a" на уровне html никогда не станет блочным элементом. а валидатор проверяет именно html и его не волнует, что в css прописано дисплей блок)

Если я не ошибаюсь, то я дал ссылку на фикс для ie6 и, например div:hover с его помощью отлично работает в ie6...

Edited January 4, 2009 by pyJee

[Виртуал]

Если я не ошибаюсь, я не видел не одного htc который бы не добавлял тормозов, глюков и работал бы как ожидается.

[pyJee]

И что теперь не пользоваться тем же пнгфикосм?

[Виртуал]

Я пользуюсь js- файлом, который подключаю только к тем стилям, которые я точно знаю что они прозрачные png, а не который как угорелый парсит все значения всех бекграундов и src картинок на соответствие шаблону .png и ставит фикс там, где не надо (восьмибитные png) и не ставит там где надо (файлы, а точнее адреса на сервере, мы же с запросами работаем, без расширения в имени запроса).

Edited January 4, 2009 by Виртуал

[SelenIT]

Дело не только в визуальном отображении. Парсер разметки не смотрит на CSS, стили применяются уже к отпарсенному DOM-дереву. Если парсер видит открывающий <p> после другого открытого <p>, ему незачем проверять, "а не сделан ли случаем этот второй <p> инлайновым" - его парсерово дело в этом случае тупо закрыть предыдущий абзац, как предписывает спецификация HTML, запрещающая вложенные абзацы.

Кроме того, у реальных браузеров (особенно старых) различается и программная модель для разных элементов. Например, в IE в Quirks mode таблицы - несколько "вещь в себе": у них по умолчанию есть layout (в отличие от др. элементов), они не наследуют стили предка, они "экранируют" ссылки и т.п. Не говоря уже об элементах форм (впрочем, их не может быть внутри ссылки по другой очевидной причине).

Чисто визуально же - чем отличается <span style="display:block"> внутри такой же "псевдоблочной" ссылки от дива в ней? Кроме того, что не сбивает с толку ни парсер, ни валидатор...

Edited January 4, 2009 by SelenIT

[Виртуал]

"a" на уровне html никогда не станет блочным элементом. а валидатор проверяет именно html и его не волнует, что в css прописано дисплей блок)

Дак о чем я иговрю — валидатор — беспомощный дурак. То, что он говорит — ничего не значит.

Чисто визуально же - чем отличается <span style="display:block"> внутри такой же "псевдоблочной" ссылки от дива в ней? Кроме того, что сбивает с толку ни парсер, ни валидатор...

На самом деле очень хороший вопрос. Возможно буду в будущем делать именно так. Спасибо.

[SelenIT]

валидатор — беспомощный дурак. То, что он говорит — ничего не значит.

Значит, хотя и не всегда буквально. Он помогает уменьшить проблемы, порожденные мифом

все браузеры строят дерево по коду, как бы элементы не были сгруппированы

[Vlad]

Знаете, любые крайности плохи. Если уж брать примеры, то получится так.

- IE6 отстой, не надо верстать под этот [цензура] [цензура] [цензура] браузер;

- Люди могут заходить на сайт с любого браузера, поэтому надо верстать в том числе и для IE6.

- Валидный код это круто, он показывает что верстка сделана грамотно;

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

Ну и так далее. У каждого высказывания найдутся свои противники и сторонники. А спорить бесполезно, здесь уже не на уровне доводов спор идет, а предпочтений. Поэтому предлагаю поднятую тему направить в одно из русел:

1. Выкладывать только мифы, которые являются "вредными", с доводами почему.

2. Выкладывать все мифы и отстаивать свою позицию.

[Ялекс]

Поддерживаю Влада, здесь начался глупый спор, как я и предпологал.

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

Еще один миф (с моей точки зрения): У всех пользователей включен JavaScript, поэтому можно смело пользоваться Ajax и новыми технологиями JavaScript.

Не так все хорошо. Сайт полностью на JS плох потому что:

1. Поисковые машины не могут собрать весь контент о сайте, потому что весь сайт собирается на стороне клиента

2. Бывают случаи, когда на клубах (во избежании вирусов) отключают JS.

3. JavaScript существенно осложняет работу с сайтом из за возможных тормозов JavaScript

4. Не исключены ошибки на стороне клиента, что полностью парализует работу сайта

5. Кэширование скриптов браузером осложняет обновление информации через JS

Можете продолжить список...

Вывод: Контент ни в коем случае нельзя передавать через JS.

Edited January 4, 2009 by Ялекс

[Игорь Ермаков]

Поддерживаю Влада, здесь начался глупый спор, как я и предпологал.

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

Еще один миф (с моей точки зрения): У всех пользователей включен JavaScript, поэтому можно смело пользоваться Ajax и новыми технологиями JavaScript.

Не так все хорошо. Сайт полностью на JS плох потому что:

1. Поисковые машины не могут собрать весь контент о сайте, потому что весь сайт собирается на стороне клиента

2. Бывают случаи, когда на клубах (во избежании вирусов) отключают JS.

3. JavaScript существенно осложняет работу с сайтом из за возможных тормозов JavaScript

4. Не исключены ошибки на стороне клиента, что полностью парализует работу сайта

5. Кэширование скриптов браузером осложняет обновление информации через JS

Можете продолжить список...

Вывод: Контент ни в коем случае нельзя передавать через JS.

а что быстрее js, ajax, php?

[Ялекс]

JavaScript (aka JS) и Asynchronous Javascript and XML (aka AJAX) фактически одно и тоже.

Ну если говорить про AJAX, то скорей это использование XMLHttpRequest для создания асинхронных запросов для получения информации с сервера.

PHP возвращает HTML, что и есть самый быстрый способ получения информации. JS/AJAX уже работают после загрузки всего контента.

Чтобы добавить или изменить информацию на страницах и используют AJAX, но его стоит применять так, чтобы пользователь с отключенным JavaScript смог иметь доступ ко всей информации.

UPD: Как то непонятно написал. Не ругайте. В голове туман(( Ниже SelenIT все доходчиво разложил

Edited January 8, 2009 by Ялекс

[Игорь Ермаков]

то есть те задачи которые можно решить с помощью php не прибегая к js лучше и решать при помощи php да?

а jQuery это я так понимаю библиотека js у неё те же самые свойства?

[SelenIT]

Игорь Ермаков, хорошим тоном считается, когда базовая функциональность доступна и без JS — через обычные ссылки и формы с перезагрузкой страницы целиком — но при включенном JS все то же самое делается плавнее, красивее и с меньшим расходом трафика (благодаря асинхронной загрузке контента по частям). Это называется "ненавязчивым" (unobtrusive) JS. Библиотека JQuery располагает хорошими инструментами для осуществления этого (напр., кроссбраузерным событием onDomLoaded), но она по определению не может быть быстрее решения на чистом JS, написанного под конкретную задачу.

А сравнивать скорость PHP и JS — все равно, что сравнивать скорость самолета и такси, идущего из аэропорта к вашему подъезду. Да, скорости разные, но маршруты и возможности — тоже...

[Игорь Ермаков]

Игорь Ермаков, хорошим тоном считается, когда базовая функциональность доступна и без JS — через обычные ссылки и формы с перезагрузкой страницы целиком — но при включенном JS все то же самое делается плавнее, красивее и с меньшим расходом трафика (благодаря асинхронной загрузке контента по частям). Это называется "ненавязчивым" (unobtrusive) JS. Библиотека JQuery располагает хорошими инструментами для осуществления этого (напр., кроссбраузерным событием onDomLoaded), но она по определению не может быть быстрее решения на чистом JS, написанного под конкретную задачу.

А сравнивать скорость PHP и JS — все равно, что сравнивать скорость самолета и такси, идущего из аэропорта к вашему подъезду. Да, скорости разные, но маршруты и возможности — тоже...

читал 3 раза. каждый раз находил в этом тексте для себя, что то ещё.

кароче учится мне ещё........

[Ялекс]

Миф: шапки, контентной части, и подвала. (флеш сайты не в счет)

Как вы думаете: это миф или нет? Стоит уходить от стереотипов?

[Vlad]

Почему же это миф? Скорее типовая модульная сетка. Традиция уже, можно сказать.

Стереотипы полезны бывают. Мне вот как-то на шведском сайте пришлось одну фотку искать. Нашел, благо структура сайта была стандартной. Так что все зависит от сайта в первую очередь.