По моему, уже сейчас поисковики вполне себе прилично отделяют зёрна от плёвел. Если в недалёком будущем ИНТЕЛЕКТУАЛЬНЫЕ устройства не смогут делать того, что сейчас умеют тупые боты, то нафиг нам такие устройства?
Не соглашусь. Все, что сейчас умеют «тупые боты», это находить в сети ответ другого человека на ваш вопрос путем соовпадения слов (утрированно). Сами ответить на него они не могут.
Почему это у колонок при табличной вёрстке нет своего обозначения и назначения? Очень даже есть. В простом варианте: меню, контент, всяка-бяка — чем не разделение по смыслу?
Вы не поняли, что я сказал. В таблицах (настоящих), есть смысловая связь по каждой вертикали и каждой горизонтали. Посмотрите на таблицу, расшифровкой значения каждой ячейки является пересечение колонки и ряда. Из этой таблицы очевидно, что метр — русское название единицы измерения длины (в системе Си — с учетом контекста документа). Это — таблица, а «меню контент, всяка-бяка» — это, простите, детский лепет (меню — это пересечение какой колонки с каким рядом?).
Создание разных версий сайта для разных устройств, например КПК. Подразумевается, что для этой версии нужно максимально облегчить и упростить страницу. Средствами CSS я действительно могу скрыть графику и ненужные блоки информации, но они ведь скроются только визуально, а реально всё равно будут грузиться (или я заблуждаюсь в этом вопросе?)
Вы опять меня не верно поняли. Для разных устройств может быть принципиально разное расположение элементов, принципиально разная визуальная структура документа. Именно поэтому половина ру(?)нета завалена дубликатами информации «для печати» и «для кпк».
Насчет загрузки — невидимые картинки (в общем случае — элементы дизайна) грузиться не будут. А размер HTML-кода не так важен — он чаще всего является небольшой частью от всего документа, ну и про round-trip-time забывать не стоит.
С жабаскриптами вообще непонятно, они вроде бы при помощи CSS не отрубаются.
Таблица (из лат. tabula «доска») — способ передачи содержания, заключающийся в организации структуры данных, в которой отдельные элементы помещены в ячейки, каждой из которых сопоставлена пара значений — номер строки и номер колонки. Таким образом устанавливается смысловая связь между элементами, принадлежащими одному столбцу или одной строке.
Т.е. «табличные верстальщики» должны четко отдавать себе отчет в том, что то, что они делают — это не таблицы. У данных в ячейках нет никакой смысловой связи между собой, у колонок и строк нет и не может быть обозначения. Все системы, пытающиеся рассматривать такую «таблицу» как таблицу будут сталкиваться с неразрешимыми проблемами.
В настоящем проблемы другие: технические (выше упомянуто не раз), адаптация для разных устройств. Знаете, html можно читать не только браузером ПК/КПК или мобильника, но также принтером, генератором голоса и черти знает еще чем — все кроме браузера ПК представит информацию не так, как хотелось бы получателю. «Табличные верстальщики» — отцы основатели совершенно идитских «версий для печати», «версий для КПК» и проч. и проч. — в HTML это ничего не нужно. Одна и та же правильно сверстанная страница прекрасно должна и может быть воспроизведена любым устройством.
второй раз за упоминание opacity рядом с IE8 получаю минус.
может кто-то осмелится высказать в чем я не прав?
Microsoft released version 8 of Internet Explorer, with full CSS level 2 support, plus some internationalization features from level 3. (Windows, free)
там плюшка не в скорости загрузки, а в отсутствии ее необходимости, для тех, у кого файл скеширован (с другого сайта).
хотя я тоже предпочитаю делать локальную копию.
нет, то что IE8 работает «не так, как …» мне показывать не надо, я это знаю и сталкивался (очень редко).
я бы хотел увидеть именно «проблемы», т.е. несоответствия стандартам.
дело в том, что люди зачастую используют селекторы и свойства css3 и потом громко ругают IE8, который совершенно честно css3 не поддерживает.
так в том то и дело, что мы жертвуем универсальностью, ничего взамен не получая (забыл это написать).
у меня, к сожалению, так и не дошли руки (хотя давно чешутся) посмотреть как в jquery реализован live, но я подозреваю, что он вешается на изменения DOM. если это так, то такой вариант как минимум в разы медленее делегирования.
не понимаю, зачем использовать два разных алгоритма для «десятка-другого» ячеек и для «тысячи-другой», если мы жертвуем универсальностью, и при этом в обоих случаях делегирование работает быстрее.
ну это немного из другой темы вопрос, поскольку .error() сработает тогда, когда сервер ответит, что картинки нет или что он не может ее дать. т.е. ответ от сервера уже придет. долгий прогресс-бар означает, что сервер затягивает с ответом (либо долго грузится большое количество ресурсов).
если бы я столкнулся с подобной проблемой, я бы в первую очередь проверил через firebug какие ресурсы грузятся дольше всего. если firebub ничего определенного не показал (проблема специфична для IE), определил происходит ли «затык» при первоначальное загрузке страницы, либо в момент «асинхронных изменений», т.е. первым делом отключил эти самые изменения. (еще можно вставить [script] $(document).ready(function() { alert(«DOM READY»); }); [/script] и посмотреть в какой момент появится alert (и появится ли вообще).
1) если проблема в первоначальной загрузке — в строке статуса должно быть написано какой ресурс грузится. если не пишется — можно попробовать поэтапно отключать ресурсы (опираясь на время загрузки, показанное в firebug — сначала наиболее долгие). и соответственно, таким методом исключения нашел источник проблемы, а дальше все зависит от его типа.
2) если проблема в асинхронности, все проще — у каждого запроса (в т.ч. .load() для картинок) есть возможность повесить callback, а значит отследить время начала и окончания загрузки, а также ее продолжительность. т.е. можно нарисовать на страницу таблицу открытых/закрытых соединений с сервером, где будет отчетливо виден ответ на Ваш вопрос.
а вот насчет flash ничего не скажу, не нравится мне эта технология и я с ней почти не работал.
приведенный ниже вариант с перекошенными бордерами и то лучше, лучше бы его в статью вставили.
скушалось.
Да, как только «сетки» будут добавлены в HTML.
А до тех пор, когда вы (не вы конкретно) пишете — вы сообщаете пользователю вашего кода о том, что это таблица, со всемы вышеизложенными вытекающими.
ps: я прекрасно понимаю, что переубедить вас невозможно.
а тогда какая разница через какую технологию это изображение на экран попало?
Не соглашусь. Все, что сейчас умеют «тупые боты», это находить в сети ответ другого человека на ваш вопрос путем соовпадения слов (утрированно). Сами ответить на него они не могут.
Вы не поняли, что я сказал. В таблицах (настоящих), есть смысловая связь по каждой вертикали и каждой горизонтали. Посмотрите на таблицу, расшифровкой значения каждой ячейки является пересечение колонки и ряда. Из этой таблицы очевидно, что метр — русское название единицы измерения длины (в системе Си — с учетом контекста документа). Это — таблица, а «меню контент, всяка-бяка» — это, простите, детский лепет (меню — это пересечение какой колонки с каким рядом?).
Вы опять меня не верно поняли. Для разных устройств может быть принципиально разное расположение элементов, принципиально разная визуальная структура документа. Именно поэтому половина ру(?)нета завалена дубликатами информации «для печати» и «для кпк».
Насчет загрузки — невидимые картинки (в общем случае — элементы дизайна) грузиться не будут. А размер HTML-кода не так важен — он чаще всего является небольшой частью от всего документа, ну и про round-trip-time забывать не стоит.
Про js я ничего не говорил.
©
Вот представьте в недалеком будущем интеллектуальные устройства, которые могут не только собирать и хранить информацию, но и анализировать ее (компьютеры, отвечающие на вопросы из любой фантастической книги). Из-за «табличных верстальщиков» подобные программы будут сталкиваться с большими трудностями в поисках упомянотой выще смысловой связи информационных элементов по горизонтали и вертикали.
Т.е. «табличные верстальщики» должны четко отдавать себе отчет в том, что то, что они делают — это не таблицы. У данных в ячейках нет никакой смысловой связи между собой, у колонок и строк нет и не может быть обозначения. Все системы, пытающиеся рассматривать такую «таблицу» как таблицу будут сталкиваться с неразрешимыми проблемами.
В настоящем проблемы другие: технические (выше упомянуто не раз), адаптация для разных устройств. Знаете, html можно читать не только браузером ПК/КПК или мобильника, но также принтером, генератором голоса и черти знает еще чем — все кроме браузера ПК представит информацию не так, как хотелось бы получателю. «Табличные верстальщики» — отцы основатели совершенно идитских «версий для печати», «версий для КПК» и проч. и проч. — в HTML это ничего не нужно. Одна и та же правильно сверстанная страница прекрасно должна и может быть воспроизведена любым устройством.
примерно неделю назад видел сюжет по телевизору, где об этом рассказывали и якобы уже все исправили, виноватых нашли и наказали :)
можете дать пруфлинк на то, что IE7 mode в IE8 отличается от нативного IE7?
(я без иронии, правда хочется узнать).
может кто-то осмелится высказать в чем я не прав?
© W3C
в css level 2 opacity нету.
В этом Вы правы.
Но в остальном слишком категоричны и предвзяты.
хотя я тоже предпочитаю делать локальную копию.
я бы хотел увидеть именно «проблемы», т.е. несоответствия стандартам.
дело в том, что люди зачастую используют селекторы и свойства css3 и потом громко ругают IE8, который совершенно честно css3 не поддерживает.
написано же «в обоих случаях делегирование работает быстрее.»
у меня, к сожалению, так и не дошли руки (хотя давно чешутся) посмотреть как в jquery реализован live, но я подозреваю, что он вешается на изменения DOM. если это так, то такой вариант как минимум в разы медленее делегирования.
preventDefault() и return false; — это разные вещи, потому что return false; помимо отмены действия отменят и bubble-эффект.
поэтому, верным будет код:
$(«popup»).click(function(e) {
// code
e.preventDefault();
e.stopPropagation();
});
что, согласитесь, не «лучше», чем return false;
если бы я столкнулся с подобной проблемой, я бы в первую очередь проверил через firebug какие ресурсы грузятся дольше всего. если firebub ничего определенного не показал (проблема специфична для IE), определил происходит ли «затык» при первоначальное загрузке страницы, либо в момент «асинхронных изменений», т.е. первым делом отключил эти самые изменения. (еще можно вставить [script] $(document).ready(function() { alert(«DOM READY»); }); [/script] и посмотреть в какой момент появится alert (и появится ли вообще).
1) если проблема в первоначальной загрузке — в строке статуса должно быть написано какой ресурс грузится. если не пишется — можно попробовать поэтапно отключать ресурсы (опираясь на время загрузки, показанное в firebug — сначала наиболее долгие). и соответственно, таким методом исключения нашел источник проблемы, а дальше все зависит от его типа.
2) если проблема в асинхронности, все проще — у каждого запроса (в т.ч. .load() для картинок) есть возможность повесить callback, а значит отследить время начала и окончания загрузки, а также ее продолжительность. т.е. можно нарисовать на страницу таблицу открытых/закрытых соединений с сервером, где будет отчетливо виден ответ на Ваш вопрос.
а вот насчет flash ничего не скажу, не нравится мне эта технология и я с ней почти не работал.
ps: opacity он поддерживать и не должен, т.к. этого свойства нет в соответствующей версии css.