...
Люди, а почему бы table не использовать а? Нет понятное дело синтаксис намного сложнее — <div></div> против <table><tr><td></td></tr></table>... Но с таблицей то сразу ясно что где отображатся будет, никаких наездов блоков друг на друга и прочие баги дивов отсутствуют...
Вдобавок как я понял — если рендеринг table во всех браузерах происходит блее менее одинаково, то за div'ами я замечал что в одном браузере все ок, в другом кучамала...
Или в чем тут дело? Почему невзирая на все проблемы с div все его все равно пользуют? Или может я настолько... гм... непрофессионален?
[RSDN@Home][1.2.0][alpha][580]
[История — это философия в примерах. [Фукидид]]
... S>Люди, а почему бы table не использовать а? Нет понятное дело синтаксис намного сложнее — <div></div> против <table><tr><td></td></tr></table>... Но с таблицей то сразу ясно что где отображатся будет, никаких наездов блоков друг на друга и прочие баги дивов отсутствуют... S>Вдобавок как я понял — если рендеринг table во всех браузерах происходит блее менее одинаково, то за div'ами я замечал что в одном браузере все ок, в другом кучамала... S>Или в чем тут дело? Почему невзирая на все проблемы с div все его все равно пользуют? Или может я настолько... гм... непрофессионален?
Люди пытаются перейти на DIV по двум причинам: 1) использование таблиц для позиционирования элементов считается deprecated, table нужно использовать только для вывода табличных данных. 2) IE показывет таблицу только после полной загрузки всего её содержимого, если в таблице много данных и, например, есть картинки, то по ощущениям, сайт грузится очень долго.
Здравствуйте, WinterMute, Вы писали:
WM>Люди пытаются перейти на DIV по двум причинам: WM>1) использование таблиц для позиционирования элементов считается deprecated, table нужно использовать только для вывода табличных данных.
ммм... А можно линк где не советуют это дело использовать? Желательно на какой-ть w3c...
WM>2) IE показывет таблицу только после полной загрузки всего её содержимого, если в таблице много данных и, например, есть картинки, то по ощущениям, сайт грузится очень долго.
C текущими тенденциями роста каналов... Гм... Вы когда последний раз на модеме в интернете были? Я вот гдето с год назад... Я к тому что удобнее с таблицами и сколько я не баловался с ними ниразу не возникало проблем с позиционированием, и tidy ниразу на это дело не ругался... Даже варнингов нету...
[RSDN@Home][1.2.0][alpha][580]
[Если только знать, но не действовать, то это равносильно неучению. [Чжу Си]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, WinterMute, Вы писали:
WM>>Люди пытаются перейти на DIV по двум причинам: WM>>1) использование таблиц для позиционирования элементов считается deprecated, table нужно использовать только для вывода табличных данных. S>ммм... А можно линк где не советуют это дело использовать? Желательно на какой-ть w3c...
Линка нет, но могу пообещать, что такое поведение table "depricated" именно W3C. Искать это нужно, скорее всего, в разделе XHTML.
WM>>2) IE показывет таблицу только после полной загрузки всего её содержимого, если в таблице много данных и, например, есть картинки, то по ощущениям, сайт грузится очень долго. S>C текущими тенденциями роста каналов... Гм... Вы когда последний раз на модеме в интернете были? Я вот гдето с год назад...
Я -- вчера .
S>Я к тому что удобнее с таблицами и сколько я не баловался с ними ниразу не возникало проблем с позиционированием,
tidi не будет ругатся, как он по-твоему поймёт что за данные в таблице находятся.
S>и tidy ниразу на это дело не ругался... Даже варнингов нету...
Знаешь, я с тобой согласен, хотя-бы потому, что сверстать сайт с более-менее нетривиальным дизайном с помошью Div-ов нереально, недоросли они ещё до этого.
Ты ведь спросил, почему люди стараются обходится Div'ами -- я ответил, хотя сам считаю попытки перехода на них преждевременными.
Помимо прочего, CSS как он есть (и первая и вторая версии) — это нагромождение костылей, которые, вдобавок, не заточены под кривые руки разработчиков браузеров.
Иногда смотришь на людей с CSS Zen Garden и то, как они превозносят CSS и думаешь — ндяяя, люди рехнулись.
В статье про CSS, которую я так и не доперевел (а на еще и платной стала в итоге ) было написано, что для полного познания CSS требуется год, а то и два Они что, с ума посходили?
ИМХО, CSS втом виде, как он есть сейчас, надо нафиг выкидывать и перелопачивать с нуля
Здравствуйте, Mamut, Вы писали:
M>Помимо прочего, CSS как он есть (и первая и вторая версии) — это нагромождение костылей, которые, вдобавок, не заточены под кривые руки разработчиков браузеров.
Костыли, не костыли... А вот то что не IE отвратительно поддерживает CSS (как и другие стандарты w3.org): http://www.webstandards.org/act/acid2/test.html
это точно.
M>Иногда смотришь на людей с CSS Zen Garden и то, как они превозносят CSS и думаешь — ндяяя, люди рехнулись.
Просто люди хотят облегчить себе жизнь и наивно полагают что нашлась таки панацея. Основная идея CSS разделение содержания и оформления. Гораздо легче править таблицу стилей в одном месте, чем кучу атрибутов по всему html. Да и тегов HTML с использованием CSS надо меньше, прощай b, i, font, etc Строить страницы с CSS гораздо легче, но... только в теории, а не в этой жизни. CSS браузеры поддерживают из рук вон плохо.
M>В статье про CSS, которую я так и не доперевел (а на еще и платной стала в итоге ) было написано, что для полного познания CSS требуется год, а то и два Они что, с ума посходили?
В том виде, в каком он на данный момент поддерживается браузерами — да, а то и больше (см. ссылку)
M>ИМХО, CSS втом виде, как он есть сейчас, надо нафиг выкидывать и перелопачивать с нуля
ИМХО, браузеры не поспевают за стандартами. Более менее поддерживается CSS1.0, да и то с оговорками. Так что пользуйтесь, но пуризмом не страдайте и пользуйтесь таблицами для оформления.
А>Просто люди хотят облегчить себе жизнь и наивно полагают что нашлась таки панацея. Основная идея CSS разделение содержания и оформления. Гораздо легче править таблицу стилей в одном месте, чем кучу атрибутов по всему html. Да и тегов HTML с использованием CSS надо меньше, прощай b, i, font, etc Строить страницы с CSS гораздо легче, но... только в теории, а не в этой жизни. CSS браузеры поддерживают из рук вон плохо.
Дело не только в браузерах но и в самом CSS.
1. Как с помощью CSS разместить элемент посреди страницы?
Табличное решение (не HTML4.01, из-за аттрибута height у таблицы, но браузеры проглатывают — они умнее w3c):
<table height="100%" width="100%">
<tr>
<td align="center">
элемент
</td>
</tr>
</table>
2. Как человеческим способом сделать fluid three-column layout с помощью CSS? О да, туториалы по этому делу есть на A List Apart и Mezzo Blue, но там шаг вправо-влево это расстрел. Прыжок на месте — тоже. От браузеров это не зависит.
3. Как заставить блочные элементы (table, div) воспринимать text-align. Или даже так — есть ли в CSS что-нибудь, что позволяет задавать align блочным элементам? Без CSS значение атрибута align влияло не только на inline элементы (span, text):
Ну и вообще, всю идею box, inline, float надо нафиг выбросить — такой кривизны мир еще не знал . Те, кто пытался с помощью CSS сделать меню по горизонтальному центру экрана на основе <ul>, которому выставлено display: inline и float: left меня поймут.
Здравствуйте, Mamut, Вы писали:
M>ЗЫ. Недавно вернулся обратно на табличный дизайн
И правильно.
HTML table использует отлитчный от всего остального алгоритм.
Никаким CSS не воспроизводимый. ни настоящим CSS 1.0 ни будущим CSS 2.1
Я имею ввиду позиционирование ячеек и вычисление размеров столбцов/рядов по их весам.
А за использование floating элементов для multicoulumn layouts я бы вообще стрелял.
Это в разы хуже (во всех смыслах) чем использование tables для этого.
Здравствуйте, <Аноним>, Вы писали:
А>Костыли, не костыли... А вот то что не IE отвратительно поддерживает CSS (как и другие стандарты w3.org): А>http://www.webstandards.org/act/acid2/test.html
Ужас!
Опера нарисовала что-то угловатое с TextBox-ом вместо глаз и повисла.
IE вообще выдал красную размазню.
Лиса была ближе всех Но и у неё не получилось нарисовать эту рожицу...
Под линухой не тестировал, а хотелось бы ещё в Konqueror загнать
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
WARNING: expression "to_be || !to_be" is always true
Здравствуйте, Mamut, Вы писали:
M>3. Как заставить блочные элементы (table, div) воспринимать text-align. Или даже так — есть ли в CSS что-нибудь, что позволяет задавать align блочным элементам? Без CSS значение атрибута align влияло не только на inline элементы (span, text): M>
Здравствуйте, WinterMute, Вы писали:
WM>Люди пытаются перейти на DIV по двум причинам: 1) использование таблиц для позиционирования элементов считается deprecated, table нужно использовать только для вывода табличных данных. 2) IE показывет таблицу только после полной загрузки всего её содержимого, если в таблице много данных и, например, есть картинки, то по ощущениям, сайт грузится очень долго.
1) Но ведь контент сайта можно представить как набор табличных данных, имхо, очень удобно.
2) Можно разбить большие таблицы на несколько маленьких и разместить их друг под другом (или рядом)
Еще один довольно веский аргумент в пользу таблиц. Вы когданибудь пробовали открвыать страницу с большим количеством DIV'ов? Кристал-репорт делает табличные отчеты с использованием дивов, если данных хотя-бы строк на 200, ослик просто виснет при попытке ресайза, мультики оперы вообще сложно описать.
... << RSDN@Home 1.1.4 beta 6a rev. 436> <под Король и шут — Волосокрад>>
M>>3. Как заставить блочные элементы (table, div) воспринимать text-align. Или даже так — есть ли в CSS что-нибудь, что позволяет задавать align блочным элементам? Без CSS значение атрибута align влияло не только на inline элементы (span, text): M>>
Ну, сразу видим косяк на кояке. В ИЕ margin: auto не поддерживается. И если я захочу выровнянный по центру div шириной 200 пикселей с текстом в нем, выровняным по правому краю, то такого мне с легкостью не добиться. Придется вводить еще один div
M>>Помимо прочего, CSS как он есть (и первая и вторая версии) — это нагромождение костылей, которые, вдобавок, не заточены под кривые руки разработчиков браузеров.
А>Костыли, не костыли... А вот то что не IE отвратительно поддерживает CSS (как и другие стандарты w3.org): А>http://www.webstandards.org/act/acid2/test.html А>это точно.
Хм, а в каких браузерах это срабатывает корректно? У меня ни FF 1.0.4, ни Opera 8.0, ни IE 6.0 не отобразили ту рожицу нормально
Здравствуйте, Mamut, Вы писали:
M>>>3. Как заставить блочные элементы (table, div) воспринимать text-align. Или даже так — есть ли в CSS что-нибудь, что позволяет задавать align блочным элементам? Без CSS значение атрибута align влияло не только на inline элементы (span, text): M>>>
M>Ну, сразу видим косяк на кояке. В ИЕ margin: auto не поддерживается. И если я захочу выровнянный по центру div шириной 200 пикселей с текстом в нем, выровняным по правому краю, то такого мне с легкостью не добиться. Придется вводить еще один div
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Mamut, Вы писали:
M>>>>3. Как заставить блочные элементы (table, div) воспринимать text-align. Или даже так — есть ли в CSS что-нибудь, что позволяет задавать align блочным элементам? Без CSS значение атрибута align влияло не только на inline элементы (span, text): M>>>>
M>>Ну, сразу видим косяк на кояке. В ИЕ margin: auto не поддерживается. И если я захочу выровнянный по центру div шириной 200 пикселей с текстом в нем, выровняным по правому краю, то такого мне с легкостью не добиться. Придется вводить еще один div
A>нет, просто у div'а нужно указать text-align...
Нет, я хочу что-нить в таком стиле:
Этот код выдаст мне вверху страницы посередине красный квадрат в котором будет выровненный по правому краю текст
<!--
Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0, IE 6.0
-->
<table align="center" width="100" height="100">
<tr>
<td align="right" bgcolor="red">
text
</td>
</tr>
</table>
По правилам CSS такой же эффект мне должен дать следующий код:
<!--
Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0
Некорректно работает в IE 6.0
-->
<div style="
background-color: #ff0000;
text-align: right;
width: 100px;
height: 100px;
margin-left: auto;
margin-right: auto">
text
</div>
Но, увы, IE не поддерживает margin: auto. Поэтому, для того, чтобы побороть его кривизну, мне надо извратиться так:
<!--
Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0, IE 6.0
-->
<div style="text-align: center; width: 100%;">
<div style="
background-color: #ff0000;
text-align: right;
width: 100px;
height: 100px;
margin-left: auto;
margin-right: auto">
text
</div>
</div>
То есть, для того, чтобы использовать CSS, мне надо знать индивидуальные глюки каждого браузера и способы их обхода. При этом использование только HTML 4.01 с дополнениями (типа аттрибут height у table) в quirks mode всех браузеров срабатывает так, как надо.
Помимо прочего, CSS код не намного нагляднее, чем повторяющий его поведение код, использующий таблицы. При выносе inline стилей в отдельные CSS-файлы положение может только усугубиться, особенно если будут добавляться дополнительные CSS хаки или возрастет количество используемых классов.
В общем, CSS это не только не панацея, но даже и не лекарство. Так, изредка полезная вещица.
Здравствуйте, Mamut, Вы писали:
M>То есть, для того, чтобы использовать CSS, мне надо знать индивидуальные глюки каждого браузера и способы их обхода. При этом использование только HTML 4.01 с дополнениями (типа аттрибут height у table) в quirks mode всех браузеров срабатывает так, как надо.
M>Помимо прочего, CSS код не намного нагляднее, чем повторяющий его поведение код, использующий таблицы. При выносе inline стилей в отдельные CSS-файлы положение может только усугубиться, особенно если будут добавляться дополнительные CSS хаки или возрастет количество используемых классов.
M>В общем, CSS это не только не панацея, но даже и не лекарство. Так, изредка полезная вещица.
некорректный пример... нужный <div> в любом случае будет вложен в другой элемент, хотя бы даже и в <body>, так же как и <table>... у этого то внешнего элемента и будут заданы необходимые стили, так что лишних тегов не появится...
M>>В общем, CSS это не только не панацея, но даже и не лекарство. Так, изредка полезная вещица.
A>некорректный пример... нужный <div> в любом случае будет вложен в другой элемент, хотя бы даже и в <body>, так же как и <table>... у этого то внешнего элемента и будут заданы необходимые стили, так что лишних тегов не появится...
Почему же некорректный? Я хочу именно такое расположение. Опять же, повторю. Для того, чтобы пользоваться CSS необходимо знать глюки каждого конкретного браузера. В приведенном мной примере пришлось вводить дополнительный, внешний div, потому что IE не обрабатывает margin: auto. И таких глюков — почти в каждом свойстве. И о каждом из этих глюков надо помнить. При этом plain HTML намного менее глючен.
А насчет корректного примера... Three-column layout. Несмотря на то, что CSS — это, теоретически, способ представления информации, он _не помогает_ ее представлять. Составление хотя бы того же three-column layout'a на CSS — это многочасовые пляски с бубном, попытки разобраться с relative и absolute позиционированием, борьба с различиями в box model в различных браузерах, абсолютно грязный хак с фоновым рисунком на странице, потому что в CSS нет способа выровнять длину различных элементов (height: 100% для дивов не работает) и так далее и тому подобное.
Причем, несмотря на все растущие разрешения мониторов, w3c практически не представляет способов относительного позиционирования на странице — любой мало-мальски человеческий дизайн, использующий CSS, опирается на попиксельное позиционирование элементов и кучу хаков. И спасения от этого не предвидется. Я не смотрел на черновой вариант CSS 3, но CSS 2.1 уже невозможно использовать...
Здравствуйте, Mamut, Вы писали:
M>>>В общем, CSS это не только не панацея, но даже и не лекарство. Так, изредка полезная вещица. A>>некорректный пример... нужный <div> в любом случае будет вложен в другой элемент, хотя бы даже и в <body>, так же как и <table>... у этого то внешнего элемента и будут заданы необходимые стили, так что лишних тегов не появится... M>Почему же некорректный? Я хочу именно такое расположение. Опять же, повторю. Для того, чтобы пользоваться CSS необходимо знать глюки каждого конкретного браузера. В приведенном мной примере пришлось вводить дополнительный, внешний div, потому что IE не обрабатывает margin: auto. И таких глюков — почти в каждом свойстве. И о каждом из этих глюков надо помнить. При этом plain HTML намного менее глючен.
потому что вот:
<!--
Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0, IE 6.0
-->
<body>
<table align="center" width="100" height="100">
<tr>
<td align="right" bgcolor="red">
text
</td>
</tr>
</table>
</body>
и вот:
<!--
Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0, IE 6.0
-->
<body style="text-align: center; width: 100%;">
<div style="background: #ff0000; text-align: right; width: 100px; height: 100px; margin: 0 auto;">
text
</div>
</body>
именно это я и имел ввиду, у любого элемента, есть родительский элемент, которым в данном случае и можно воспользоваться...
M>А насчет корректного примера... Three-column layout. Несмотря на то, что CSS — это, теоретически, способ представления информации, он _не помогает_ ее представлять. Составление хотя бы того же three-column layout'a на CSS — это многочасовые пляски с бубном, попытки разобраться с relative и absolute позиционированием, борьба с различиями в box model в различных браузерах, абсолютно грязный хак с фоновым рисунком на странице, потому что в CSS нет способа выровнять длину различных элементов (height: 100% для дивов не работает) и так далее и тому подобное.
может стоит отказаться от трёхколоночной верстки?... не вижу за ней никаких преимуществ...
M>Причем, несмотря на все растущие разрешения мониторов, w3c практически не представляет способов относительного позиционирования на странице — любой мало-мальски человеческий дизайн, использующий CSS, опирается на попиксельное позиционирование элементов и кучу хаков. И спасения от этого не предвидется. Я не смотрел на черновой вариант CSS 3, но CSS 2.1 уже невозможно использовать...
A><!--
A> Рабочий код, одинаково ведет себя в FF 1.0.4, Opera 8.0, IE 6.0
-->>
A><body style="text-align: center; width: 100%;">
A> <div style="background: #ff0000; text-align: right; width: 100px; height: 100px; margin: 0 auto;">
A> text
A> </div>
A></body>
A>
A>именно это я и имел ввиду, у любого элемента, есть родительский элемент, которым в данном случае и можно воспользоваться...
И все равно мне надо знать, что:
— в IE margin: auto не работает
— в FF/Opera text-align не воздействует на блочные элементы
— в FF/Opera margin: auto работает
— в IE text-align воздействует на блочные элементы
Если исключить тривиальные случаи, то CSS не предоставляет никаких преимуществ по сравнению со старым табличным дизайном страницы. CSS может слегка помочь такими свойствами, как border, background, но не более.
Например. Мне хочется сделать себе на сайте меню, которое размещалось бы вверху посередине страницы. Следуя советам [url=http://CSS-водов, я беру в руки ul и li и начинаю их извращать свойствами display: inline, float: left и так далее. и тут оказывается, что из-за float я не могу это дело позиционировать в центре страницы.
В общем, усть такая вот весьма объективная статья:
One of the reasons the web has been so successful, is it’s low barrier to entry. HTML is a simple “language” to learn and browsers are very forgiving about poorly formed documents. This makes it incredibly easy for anybody to publish on the web. Even your 12 year old nephew could knock up a simple site using the copy of Frontpage that comes bundled with Microsoft Office.
Compare table based design to CSS based design...In my experience, there is probably around a 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently...
... Is it any wonder why web developers turn their back on CSS when even simple things are rendered so complicated when you stop using tables....
Ну и вдогонку вот такая вот статейка и ее обоснование.
[q] Anyone can build a fixed-pixel layout in CSS with known font sizes, that’s easy stuff. Build me a liquid three column layout that allows for text scaling in Internet Explorer, and watch how easy it is to break by increasing your font size. Especially once the code leaves your hands. This is where it gets hard, folks.
[q]
M>>А насчет корректного примера... Three-column layout. Несмотря на то, что CSS — это, теоретически, способ представления информации, он _не помогает_ ее представлять. Составление хотя бы того же three-column layout'a на CSS — это многочасовые пляски с бубном, попытки разобраться с relative и absolute позиционированием, борьба с различиями в box model в различных браузерах, абсолютно грязный хак с фоновым рисунком на странице, потому что в CSS нет способа выровнять длину различных элементов (height: 100% для дивов не работает) и так далее и тому подобное.
A>может стоит отказаться от трёхколоночной верстки?... не вижу за ней никаких преимуществ...
На глазок процентов 95 сайтов используют колоночный дизайн страниц: www.microsoft.com — две колонки и рудиментарная третья (дополнительная информация, которая появляется в виде вставок справа) www.sf.net, www.codeproject.com — две колонки www.alistapart.com — две колонки, fixed layout www.csszengarden.com — в основном две колонки, fixed layout, хотя есть и варианты
ну и так далее
M>>Причем, несмотря на все растущие разрешения мониторов, w3c практически не представляет способов относительного позиционирования на странице — любой мало-мальски человеческий дизайн, использующий CSS, опирается на попиксельное позиционирование элементов и кучу хаков. И спасения от этого не предвидется. Я не смотрел на черновой вариант CSS 3, но CSS 2.1 уже невозможно использовать...
A>вот это к таблицам уже отношения не имеет...
Имеет то отношение, что несмотря на работу w3c evangelists, табличный дизайн все равно остается наиболее легким в применении
В общем, надо идти на компромиссы Использовать легковесные таблицы и CSS в одном документе — потому что это пока единственный способ быстро и качественно сделать сайт, который будет отображаться у всех одинаково
Здравствуйте, Mamut, Вы писали:
M>И все равно мне надо знать, что: M>- в IE margin: auto не работает M>- в FF/Opera text-align не воздействует на блочные элементы M>- в FF/Opera margin: auto работает M>- в IE text-align воздействует на блочные элементы
не совсем так... в самом общем случае тебе надо знать стандарты W3C и глюки MSIE...
M>Если исключить тривиальные случаи, то CSS не предоставляет никаких преимуществ по сравнению со старым табличным дизайном страницы. CSS может слегка помочь такими свойствами, как border, background, но не более.
у блочной верстки другая цель: отделить разметку от содержания...
M>Например. Мне хочется сделать себе на сайте меню, которое размещалось бы вверху посередине страницы. Следуя советам [url=http://CSS-водов, я беру в руки ul и li и начинаю их извращать свойствами display: inline, float: left и так далее. и тут оказывается, что из-за float я не могу это дело позиционировать в центре страницы.
статьи потом почитаю, с английским туго, читать буду долго...
A>>может стоит отказаться от трёхколоночной верстки?... не вижу за ней никаких преимуществ... M>На глазок процентов 95 сайтов используют колоночный дизайн страниц: M>www.microsoft.com — две колонки и рудиментарная третья (дополнительная информация, которая появляется в виде вставок справа) M>www.sf.net, www.codeproject.com — две колонки M>www.alistapart.com — две колонки, fixed layout M>www.csszengarden.com — в основном две колонки, fixed layout, хотя есть и варианты M>ну и так далее
вся эта статистика ни о чем не говорит... колонки — это привычка, оставшаяся от "табличных времен"... люди так привыкли: и пользователи и дизайнеры... и в массе мало кто пытается искать новые решения в плане оформления содержания...
M>>>Причем, несмотря на все растущие разрешения мониторов, w3c практически не представляет способов относительного позиционирования на странице — любой мало-мальски человеческий дизайн, использующий CSS, опирается на попиксельное позиционирование элементов и кучу хаков. И спасения от этого не предвидется. Я не смотрел на черновой вариант CSS 3, но CSS 2.1 уже невозможно использовать... A>>вот это к таблицам уже отношения не имеет... M>Имеет то отношение, что несмотря на работу w3c evangelists, табличный дизайн все равно остается наиболее легким в применении
легче не значит лучше... )
M> M>В общем, надо идти на компромиссы Использовать легковесные таблицы и CSS в одном документе — потому что это пока единственный способ быстро и качественно сделать сайт, который будет отображаться у всех одинаково
это уже зависит от ТЗ...
Re[7]: div vs table
От:
Аноним
Дата:
02.08.05 09:30
Оценка:
Здравствуйте, Mamut, Вы писали:
..skipped.. А>>http://www.webstandards.org/act/acid2/test.html
M>Хм, а в каких браузерах это срабатывает корректно? У меня ни FF 1.0.4, ни Opera 8.0, ни IE 6.0 не отобразили ту рожицу нормально
Корректно только Safari прошёл тест. Mozilla (FF) пока не собирается его проходить, мотивируя тем что есть более важные фичи в CSS2 которые надо поддержать. Про IE и говорить нечего, он не очень хорошо HTML стандарт поддерживает, что там говорить о CSS.
Впрочем, ссылка это просто иллюстрация неподготовленности браузеров к стандартам CSS.
M>>И все равно мне надо знать, что: M>>- в IE margin: auto не работает M>>- в FF/Opera text-align не воздействует на блочные элементы M>>- в FF/Opera margin: auto работает M>>- в IE text-align воздействует на блочные элементы
A>не совсем так... в самом общем случае тебе надо знать стандарты W3C и глюки MSIE...
Или то, что в Опере у страницы (BODY) на до выставлять не margin: 0px, a padding: 0px. И что во избежание глюков при работе со списками надо ставить им и margin и padding равными нулю В общем, глюков повсюду хватает...
M>>Если исключить тривиальные случаи, то CSS не предоставляет никаких преимуществ по сравнению со старым табличным дизайном страницы. CSS может слегка помочь такими свойствами, как border, background, но не более.
A>у блочной верстки другая цель: отделить разметку от содержания...
Это в теории, а на практике это оборачивается воплями и психиатрической больницей
M>>Например. Мне хочется сделать себе на сайте меню, которое размещалось бы вверху посередине страницы. Следуя советам [url=http://CSS-водов, я беру в руки ul и li и начинаю их извращать свойствами display: inline, float: left и так далее. и тут оказывается, что из-за float я не могу это дело позиционировать в центре страницы.
A>зачем там float?...
В общем, там идея сводится к тому, что надо использовать гибридный подход, особенно если решение с помощью CSS слишком муторно (в статьях приводятся в качестве примера сложные формы и попытка сделать footer при помощи CSS)
A>>>может стоит отказаться от трёхколоночной верстки?... не вижу за ней никаких преимуществ... M>>На глазок процентов 95 сайтов используют колоночный дизайн страниц: M>>www.microsoft.com — две колонки и рудиментарная третья (дополнительная информация, которая появляется в виде вставок справа) M>>www.sf.net, www.codeproject.com — две колонки M>>www.alistapart.com — две колонки, fixed layout M>>www.csszengarden.com — в основном две колонки, fixed layout, хотя есть и варианты M>>ну и так далее
A>вся эта статистика ни о чем не говорит... колонки — это привычка, оставшаяся от "табличных времен"... люди так привыкли: и пользователи и дизайнеры... и в массе мало кто пытается искать новые решения в плане оформления содержания...
Пока что колонки — наиболее эффективный способ представить информаию на сайте, имхо. С удовольствием могу переубедиться
M>>>>Причем, несмотря на все растущие разрешения мониторов, w3c практически не представляет способов относительного позиционирования на странице — любой мало-мальски человеческий дизайн, использующий CSS, опирается на попиксельное позиционирование элементов и кучу хаков. И спасения от этого не предвидется. Я не смотрел на черновой вариант CSS 3, но CSS 2.1 уже невозможно использовать... A>>>вот это к таблицам уже отношения не имеет... M>>Имеет то отношение, что несмотря на работу w3c evangelists, табличный дизайн все равно остается наиболее легким в применении
A>легче не значит лучше... )
Не спорю.
M>> M>>В общем, надо идти на компромиссы Использовать легковесные таблицы и CSS в одном документе — потому что это пока единственный способ быстро и качественно сделать сайт, который будет отображаться у всех одинаково
A>это уже зависит от ТЗ...
Здравствуйте, Mamut, Вы писали:
A>>зачем там float?... M>Это я про вот это вот меню
все равно не понял зачем там float...
M>>>В общем, усть такая вот весьма объективная статья: M>>>Ну и вдогонку вот такая вот статейка и ее обоснование. A>>статьи потом почитаю, с английским туго, читать буду долго... M>В общем, там идея сводится к тому, что надо использовать гибридный подход, особенно если решение с помощью CSS слишком муторно (в статьях приводятся в качестве примера сложные формы и попытка сделать footer при помощи CSS)
с этим я согласен... в конце концов правильная верстка как самоцель нужна только в проектах "для души"...
A>>вся эта статистика ни о чем не говорит... колонки — это привычка, оставшаяся от "табличных времен"... люди так привыкли: и пользователи и дизайнеры... и в массе мало кто пытается искать новые решения в плане оформления содержания... M>Пока что колонки — наиболее эффективный способ представить информаию на сайте, имхо. С удовольствием могу переубедиться
A>>>зачем там float?... M>>Это я про вот это вот меню
A>все равно не понял зачем там float...
Я тоже Но там какой-то хак для ИЕ
M>>В общем, там идея сводится к тому, что надо использовать гибридный подход, особенно если решение с помощью CSS слишком муторно (в статьях приводятся в качестве примера сложные формы и попытка сделать footer при помощи CSS)
A>с этим я согласен... в конце концов правильная верстка как самоцель нужна только в проектах "для души"...
A>>>вся эта статистика ни о чем не говорит... колонки — это привычка, оставшаяся от "табличных времен"... люди так привыкли: и пользователи и дизайнеры... и в массе мало кто пытается искать новые решения в плане оформления содержания... M>>Пока что колонки — наиболее эффективный способ представить информаию на сайте, имхо. С удовольствием могу переубедиться
A>http://cssimport.com/
Здравствуйте, Mamut, Вы писали:
A>>>>зачем там float?... M>>>Это я про вот это вот меню A>>все равно не понял зачем там float... M>Я тоже Но там какой-то хак для ИЕ
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Mamut, Вы писали: А>..skipped.. А>>>http://www.webstandards.org/act/acid2/test.html
M>>Хм, а в каких браузерах это срабатывает корректно? У меня ни FF 1.0.4, ни Opera 8.0, ни IE 6.0 не отобразили ту рожицу нормально
А>Корректно только Safari прошёл тест. Mozilla (FF) пока не собирается его проходить, мотивируя тем что есть более важные фичи в CSS2 которые надо поддержать. Про IE и говорить нечего, он не очень хорошо HTML стандарт поддерживает, что там говорить о CSS.
А>Впрочем, ссылка это просто иллюстрация неподготовленности браузеров к стандартам CSS.
у меня на сафари не прошло, картинка примерно как в Opere 8
M>>ИМХО, CSS втом виде, как он есть сейчас, надо нафиг выкидывать и перелопачивать с нуля
Абсолютно согласен!
А>ИМХО, браузеры не поспевают за стандартами. Более менее поддерживается CSS1.0, да и то с оговорками. Так что пользуйтесь, но пуризмом не страдайте и пользуйтесь таблицами для оформления.
Это не браузеры не поспевают за стандартами, а стандарты оторвались от реалий. Посмотришь на стандарты — пухлые фолианты, но из них используется в реальной жизни только процентов 10%, и то в лучшем случае.
Стандарт болжен быть краток и понятем. Теже таблицы — лаконичны, поэтому и используются, но к сожалению главную проблему разделения дизайна и наполнения не выполняют.
А разработчики стандартов: о нам вот этой фичи еще не хватало, давайте добавим. А то что все остальное даже не на костылях, а еще еле ползает, их не заботит.
ЗЫ. К сожалению данная тенденция прослеживается во многих областях Когда не знают как сделать в общем, пытаются описать каждый частный случай
... S>Люди, а почему бы table не использовать а? Нет понятное дело синтаксис намного сложнее — <div></div> против <table><tr><td></td></tr></table>... Но с таблицей то сразу ясно что где отображатся будет, никаких наездов блоков друг на друга и прочие баги дивов отсутствуют... S>Вдобавок как я понял — если рендеринг table во всех браузерах происходит блее менее одинаково, то за div'ами я замечал что в одном браузере все ок, в другом кучамала... S>Или в чем тут дело? Почему невзирая на все проблемы с div все его все равно пользуют? Или может я настолько... гм... непрофессионален?
Div удобней позиционировать, переносить блоки при редизайне. Таблицами такие возможности недоступны.
Здравствуйте, MBy, Вы писали:
ОГ>>Div удобней позиционировать, переносить блоки при редизайне. Таблицами такие возможности недоступны.
MBy>Во-во, согласен. Читай: слои.
Div-ами такую феньку реально сделать? Там центровка контента фиксированного размера по горизонтали, по вертикали, толпа мелких ссылок и копирайтов в подвале страницы обязательно должна уйти за пределы видимой области окна, конечно же если размер вмещает главный контент, а иначе — во весь рост, как здесь.
Сам уважаю компактный, логически структурированный код, но просто так задолбался ковыряться с дивами, удовлетворяя весь браузерный зоопарк, что плюнул на них и сделал всё табличным образом — работает.
Здравствуйте, Xander Zerge, Вы писали:
ОГ>>>Div удобней позиционировать, переносить блоки при редизайне. Таблицами такие возможности недоступны.
MBy>>Во-во, согласен. Читай: слои.
XZ>Div-ами такую феньку реально сделать?
Ты знаешь, мне кажеться, что нет ничего невозможного (: Вот судить реально, то СSS + DIV дают куда больше возможностей по воплощению чего-то необычного и оригинального. Спецификация предоставляет уйму вкусных вещей — плохо, что многие попросту не поддерживают их, либо (еще хуже) поддерживают по разному и/или неправильно. Вот корень бед.
Сейчас при себе нет ссылок, что бы показать на примере реализацию твоего случая, но вот нашел такой сайт: http://css-discuss.incutio.com/?page=ThreeColumnLayouts
Глянь, может будет что-то похожее. А там и видно будет (:
XZ>Сам уважаю компактный, логически структурированный код, но просто так задолбался ковыряться с дивами, удовлетворяя весь браузерный зоопарк, что плюнул на них и сделал всё табличным образом — работает.
Я согласен с тобой в том плане, что таблицы — это надежно, быстро и просто. Но если ты разделяешь со мной идеи семантической сети, то согласишься, что это неправильно. CSS — это всего-лишь одежка. Информация должна быть доступна легко и без графического ее представления (нужен реальный пример? а ты открой свой сайт, и какой-то CSS + DIV сайт на мобильном).
Таблицы, также, дают простую возможность создания сетки/каркаса/layout, подобно такому как используют в издательском деле. Но с другой стороны — действительно ли это нам везде и повсеместно так необходимо?
Здравствуйте, MBy, Вы писали:
MBy>Сейчас при себе нет ссылок, что бы показать на примере реализацию твоего случая, но вот нашел такой сайт: http://css-discuss.incutio.com/?page=ThreeColumnLayouts MBy>Глянь, может будет что-то похожее. А там и видно будет (:
У него там обычная двухколоночная вёрска. Ничего особенного.
Здравствуйте, MBy, Вы писали:
MBy>Ты знаешь, мне кажеться, что нет ничего невозможного (: Вот судить реально, то СSS + DIV дают куда больше возможностей по воплощению чего-то необычного и оригинального. Спецификация предоставляет уйму вкусных вещей — плохо, что многие попросту не поддерживают их, либо (еще хуже) поддерживают по разному и/или неправильно. Вот корень бед.
Дивы действительно заманчиво для получения красивых эффектов. Но каждому действительно своё место. И не будем как таблицы, так и дивы наделять какими-то универсальными свойствами. Если я не собираюсь тратить уйму времени на создание кроссплатформенного шаблона сайта — стопроцентно это таблицы для жестко фиксированных элементов, в результате я получаю гарантию верного отображения внешнего вида сайта, и использование дивов — для получения динамики, компоновки вывода данных, получения спецэффектов.
Здравствуйте, LW001, Вы писали:
LW>Если я не собираюсь тратить уйму времени на создание кроссплатформенного шаблона сайта — стопроцентно это таблицы для жестко фиксированных элементов
А я предпочитаю «поиграться», но получить качественный результат. И мне кажеться, что для «фиксированного» макета div подходит прекрасно. В том плане, что если фиксированный, то абсолютное позиционирование, а оно проще реализуется блоками. Хотя опять же — бывают разные случаи.
Здравствуйте, MBy, Вы писали:
MBy>А я предпочитаю «поиграться», но получить качественный результат. И мне кажеться, что для «фиксированного» макета div подходит прекрасно. В том плане, что если фиксированный, то абсолютное позиционирование, а оно проще реализуется блоками. Хотя опять же — бывают разные случаи.
"Поиграться" и я не против, но иногда результат требуют сиюже минуту. Как правильно заметил — бывают разные случаи, а они не допустимы.
И кроме того — я за то, что бы не мудрить там, где этого не требуется. А для скорости загрузки — неплохо было бы оптимизировать графику, а то иногда такое встречается! Взялись мы как-то представлять в России одну Британскую компанию, взглянул я на их сайт.... Когда картинки 600 на 480 точек выводятся как 100 на 80... И так весь каталог...
Дивы хороши там, где пользователю надо дать динамику и возможность выполнять какие-то действия, по типу перетаскивания, сортировки объектов, всяческих перемещений по рабочей области, итп. Здесь их превосходство несомненно.
Мы все понимаем, что этот пример не совсем корректен Потому что цикл In search of the One True Layout прекрасно раскрывает все мучения, которые надо преодолеть для того, чтобы такое сваять.
На самом деле, как где-то уже упоминал c-smile, для того, чтобы без проблем создавать layout любой сложности, в текущий CSS достаточно ввести всего два изменения.
Сколько умов трудилось над этой проблемой — неперечесть.
Divы — это правильно и удобно. Я как правило таблицами для разметки уже не пользуюсь и при отрисовке дизайна учитываю этот момент — и проблем нет. Вот последний печальный пример http://samurai.fareastmotors.ru, да и сам http://www.fareastmotors.ru — удобно.
Здравствуйте, Ветер, Вы писали:
В>Сколько умов трудилось над этой проблемой — неперечесть. В>Divы — это правильно и удобно. Я как правило таблицами для разметки уже не пользуюсь и при отрисовке дизайна учитываю этот момент — и проблем нет. Вот последний печальный пример http://samurai.fareastmotors.ru, да и сам http://www.fareastmotors.ru — удобно.
Вот — вот, печальный... Менюшка на последнем сайте при уменьшении ширины окна выползает куда ей не надо...
Здравствуйте, LW001, Вы писали:
LW>Здравствуйте, Ветер, Вы писали:
В>>Сколько умов трудилось над этой проблемой — неперечесть. В>>Divы — это правильно и удобно. Я как правило таблицами для разметки уже не пользуюсь и при отрисовке дизайна учитываю этот момент — и проблем нет. Вот последний печальный пример http://samurai.fareastmotors.ru, да и сам http://www.fareastmotors.ru — удобно.
LW>Вот — вот, печальный... Менюшка на последнем сайте при уменьшении ширины окна выползает куда ей не надо...
Печальный не в плане верстки, а в плане — денег не заплатили. Что касается прыгания элементов при уменьшении размеров — я тоже сначала думал, мол, плохо. А потом стал рассуждать иначе — при всей нелепости этого процесса, страница всё таки пытается быть шириной под окно браузера — это гораздо удобней нежели полосы прокрутки по которым надо ездить туда-сюда . Избежать этого процесса достаточно просто — задать min-width для body например. Но я не делал этого намеренно из-за выше указанной причины. Таблицы, увы, таких возможностей не дают.
Кроме того, таблицы имеют способность засерать мозг. Имел удовольствие неоднократно наблюдать как народ начанает их использовать везде и всюду, например, есть горизонтальное размещение элементов одного под другим, где можно в общем-то обойтись даже переносами, однако в силу привычки, человек делает это отдельными ячейками таблицы.
Здравствуйте, Ветер, Вы писали:
В>... Таблицы, увы, таких возможностей не дают. В>Кроме того, таблицы имеют способность засерать мозг. Имел удовольствие неоднократно наблюдать как народ начанает их использовать везде и всюду, например, есть горизонтальное размещение элементов одного под другим, где можно в общем-то обойтись даже переносами, однако в силу привычки, человек делает это отдельными ячейками таблицы.
Вот и я говорю о том же. Не надо убеждать всех и вся, а себя в первую очередь, что таблицы, или же дивы — сами по себе панацея от всех бед и лишений )) У каждого элемента в разметке страницы — своя собственная задача, свои свойства, и если в чем-то они перекрываются, то какие-то их свойства не заменить ничем. У Div-ов например — z-index, что позволяет делать многослойную структуру, легко перемещать слои относительно друг друга в зависимости от задачи. У таблиц (про простой вывод табличных данных упоминать не будем — как о само собой разумеющемся) — деление области экрана на рабочие области, в которые впмчываются слои, если таковое необходимо. Например, когда один слой привязан к правому краю, а другой — к левому, и необходимо, чтобы они перекрывались только до определенного размера.
А min-width... IE7 понимать его научился, но 6-ой — нет. А на нем сидит подавляющее большинство.
Я тоже раньше полагал, что необходимо знать глюки каждого браузера, однако с практикой убедился, что надо всего лишь недопускать неопределенностей в интерпретации вашей визуальной модели страницы. Честно говоря, мне достаточно сложно формально описать все правила которыми приходится руководствоваться (это скорей навык), однако никаких особенных трудностей сейчас не возникает.
Касательно глюков и браузеров. Глюки есть везде и в ие и в ff и опера. Причем попадались и нередко глюки в фф и опера, и что характерно — ие вел себя правильно и что немаловажно — нормативно.
Основное заблуждение (на мой взгляд), которое протаскивается в топике таково: html и css имеют определенную идеалогию, которую выражают такие логические элементы как h?, strong, em, cite, address, table, ins, del ... и прочие. Внесение такой порнографии в html как font, b, i, sup, sub (насколько мне известно нетскейпом) — дало чисто визуальный временный эффект, но сильно исказило основную идею и усложнило жизнь всем. Далее, хтмл начал просто использоваться не по назначению — хтмл — это семантика документа в первую очередь — а не язык визуальной разметки, что тоже не мало важно и чем занимается CSS. Как я понимаю, раннее допущенные в стандарт порно-элементы (аттрибуты) стараются постепенно убрать из языка, ставя пометку depricated. Требование вроде "хочу чтобы в css все было как в table" — противоречит самой идее хтмл, никто же не требует от окна браузера чтобы оно было круглым и для размещения использовалась полярная система координат. В конце концов есть флэш, который может воплотить любую идею любого мега дизайнера, и поисковиками он вроде индексируется.
Здравствуйте, Amidlokos, Вы писали:
А>>http://www.webstandards.org/act/acid2/test.html A>Опера нарисовала что-то угловатое с TextBox-ом вместо глаз и повисла.
Девятая опера полностью корректно проходит этот тест.
A>IE вообще выдал красную размазню.
Ага.
A>Лиса была ближе всех Но и у неё не получилось нарисовать эту рожицу...
Лиса как раз посередине между тремя.
A>Под линухой не тестировал, а хотелось бы ещё в Konqueror загнать
Если моя память не спит с другим, то Konqueror сделан на движке Gecko, а это значит, на том же, что и Лиса. То есть, результат ты получишь тот же. (Поправьте знающие, если ошибаюсь.)
Здравствуйте, Аноним, Вы писали:
А>>>http://www.webstandards.org/act/acid2/test.html А>Впрочем, ссылка это просто иллюстрация неподготовленности браузеров к стандартам CSS.
Чушь! Этот тест и сам не проходит валидации по CSS.
Здравствуйте, gwg-605, Вы писали:
M>>>ИМХО, CSS втом виде, как он есть сейчас, надо нафиг выкидывать и перелопачивать с нуля G6>Абсолютно согласен! А>>ИМХО, браузеры не поспевают за стандартами.
Просто им влом реализовывать все и вся, особенно точно так, как пишет бумага.
Ну вот тебе ведь будет несколько проще нафантазировать новых фич для нового стандарта, а кто возьмется их реализовывать? (: Тут похожая ситуация, по-моему.
Кстати, мой приятель говорил когда-то, что HTML — это ошибка в корне. Нужно было использовать PostScript (= (просто он в издательском деле работает).
G6>Это не браузеры не поспевают за стандартами, а стандарты оторвались от реалий. Посмотришь на стандарты — пухлые фолианты, но из них используется в реальной жизни только процентов 10%, и то в лучшем случае.
Не стоит забывать о могучем и страшном словосочетании «обратная совместимость» (;
Вспомни первые версии HTML. Да что там, хотя бы вот элемент FONT! Ведь он устарел. Но тем не менее существует в XHTML 1.0 Transitional (хоть в Strict его убрали…)
Вот ты сейчас возьмешь, все выбросишь и сделаешь новый, пускай даже действительно супер классный новый стандарт. И что? Ты миллионы IE6 так и остануться…
> Вот ты сейчас возьмешь, все выбросишь и сделаешь новый, пускай даже действительно супер классный новый стандарт. И что? Ты миллионы IE6 так и остануться…
Я бы деньги поставил на то, что если сделать нормальную технологию для WEB, то большинство переедет очень быстро. Это всё-равно что всё жизнь есть морковку и попробовать какой-нибудь рядовой баунти.
Кажется очевидным — объектная модель, унификация форматов, каркасов и выравниваний, методов позиционирования, управления размерами, ... оформлений, свойств...
>> Вот ты сейчас возьмешь, все выбросишь и сделаешь новый, пускай даже действительно супер классный новый стандарт. И что? Ты миллионы IE6 так и остануться…
G>Я бы деньги поставил на то, что если сделать нормальную технологию для WEB, то большинство переедет очень быстро.
«очень быстро» — это сколько лет? (:
Ты не путай веб-разработчиков и «простых смертных». И подумай какой авторитет нужно иметь, что бы повлиять на таких гигантов, как тот же Microsoft. А ведь именно он имеет наибольший процент от общего к-ва используемых браузеров.
>> Вот ты сейчас возьмешь, все выбросишь и сделаешь новый, пускай даже действительно супер классный новый стандарт. И что? Ты миллионы IE6 так и остануться…
G>Я бы деньги поставил на то, что если сделать нормальную технологию для WEB, то большинство переедет очень быстро. Это всё-равно что всё жизнь есть морковку и попробовать какой-нибудь рядовой баунти. G>Кажется очевидным — объектная модель, унификация форматов, каркасов и выравниваний, методов позиционирования, управления размерами, ... оформлений, свойств...
Все правильно и про ИЕ6 — но это преодалевается скриптами, да и если покапаться для ие ведь и css может быть динамическим.
Главный момент который я хотел подметить — вы разделяете элементы по их функциональным возможностям — это есть неправильно на мой взгляд. Таблица — это не группа прямоугольных областей, которые могут равнятся по высоте (строчки) или ширине (колонки) и следовательно в них нужно пихать все что угодно, таблица — это контейнер для данных, родственик, так сказать, таблицы базы данных. И потому не стоит ее использовать не по назначению — для разметки. Возможно, если бы все строго подходили к этому вопросу, у нас были бы встроенные в браузер средства для работы с табличными данными — сортировки, поиски и пр. Но поскольку содержимое никак не рагламентируется, то и отсутствуют средства работы с ним.
Точно так же с дивами (спэнами) — его назначение — визуальный контейнер — блок html елементов — элемент разметки. Z-index — это не показание к применению (кстати, насколько мне известно z-index можно проставлять кому угодно).
И еще момент, спецификации css — довольно мощная штука, и в ней много интересных решений — надо вчитаться (это не упрек, это личные впечатления). Возможно это будет интересным — css предусматривает возможность задания группам элементов табличного поведения. К сожалению ИЕ6 эту возможность не поддерживает.
Буквально пару лет назад я бился в тех же спорах. Постепенная эволюция и практика привела к текущим возрениям.
Здравствуйте, crackoff, Вы писали:
C>Еще один довольно веский аргумент в пользу таблиц. Вы когданибудь пробовали открвыать страницу с большим количеством DIV'ов? Кристал-репорт делает табличные отчеты с использованием дивов, если данных хотя-бы строк на 200, ослик просто виснет при попытке ресайза, мультики оперы вообще сложно описать.
Кто ж виноват, что разработчики Кристал-репорт поддались на провокацию? Где данные табличные, там надо использовать таблицы. Слои же для нетабличных данных.
Давайте просто подумаем на досуге, почему приходится не пользоваться инструментами, а править всё ручками, а на сайтах частенько экспериментировать с отлетевшими менюшками
И не будем здесь это обсуждать. Если вы останетесь при своем мнении, что нужно просто всё "выровнять", то я не буду возражать. А если появится удовлетворяющая меня технология, то просто ею воспользуюсь. И буду радоваться, что эра HTML+CSS+фиг-знает-чё прошла...
По поводу того, почему народ пытается использовать divы, а не таблицы или еще что.
Причина — одна. ПОтому что это CSS-совместимо, а значит можно изменить всю раскладку страницы, просто поменяв один CSS-стиль. Все. Таблица — она фиксирует элементы, сколько бы ячеек в ней не было — одна или две, или тысяча.
Все что верстается таблицей — может быть сверстано дивами. Даже таблица в N строк и M столбцов. Один гемор у этого всего только, что нельзя нормально выровнять ПО ВЫСОТЕ внутри блока div так чтобы это смотрелось одинакого во всех брайзерах. Приходится прибегать с различного рода кросс-браузерным хакам. Вот это настоящий гемор. А все остальное — это просто почти сказка. Почти.
Здравствуйте, MBy, Вы писали:
MBy>Просто им влом реализовывать все и вся, особенно точно так, как пишет бумага.
Ну допустим сделали все эти фичи, и сколько народа будет это использовать?
MBy>Ну вот тебе ведь будет несколько проще нафантазировать новых фич для нового стандарта, а кто возьмется их реализовывать? (: Тут похожая ситуация, по-моему.
Если стандарт будет помещаться на 10-ти листах, то реализация его будет стоить копейки и понятен он будет значительно большему количеству людей. пример: тот же базовый HTML.
MBy>Кстати, мой приятель говорил когда-то, что HTML — это ошибка в корне. Нужно было использовать PostScript (= (просто он в издательском деле работает).
Я врагу не пожелаю такого.
MBy>Не стоит забывать о могучем и страшном словосочетании «обратная совместимость» (;
это отмазки. Вспомни OS/2 которая сильно заботилась об обратной совместимости, и где она?
MBy>Вспомни первые версии HTML. Да что там, хотя бы вот элемент FONT! Ведь он устарел. Но тем не менее существует в XHTML 1.0 Transitional (хоть в Strict его убрали…)
Так я о том же, что тот же FONT существует до сих пор, поскольку это была достаточно удачнная идея, которая многим понятна.
MBy>Вот ты сейчас возьмешь, все выбросишь и сделаешь новый, пускай даже действительно супер классный новый стандарт. И что? Ты миллионы IE6 так и остануться…
Неа, не буду я уже нашел средство которое мне поможет, это HTML+XML+XSLT Просто не надо пытаться запихнуть слона в спичесную коробку. HTML это внешний вид(он изначально разрабатывался для этого), XML это данные, XSLT правила преобразования, вот мы и отделили представления от данных, не изобретая тонны стандартов.
G>Давайте просто подумаем на досуге, почему приходится не пользоваться инструментами, а править всё ручками, а на сайтах частенько экспериментировать с отлетевшими менюшками G>И не будем здесь это обсуждать. Если вы останетесь при своем мнении, что нужно просто всё "выровнять", то я не буду возражать. А если появится удовлетворяющая меня технология, то просто ею воспользуюсь. И буду радоваться, что эра HTML+CSS+фиг-знает-чё прошла...
Так я тоже не против Но вот не видно этой технологии в обозримом будущем (Тем более, что даже если такая технология появится, переход на нее будет длиться годами)
Здравствуйте, PaulMinelly, Вы писали:
PM>Причина — одна. ПОтому что это CSS-совместимо, а значит можно изменить всю раскладку страницы, просто поменяв один CSS-стиль. Все. Таблица — она фиксирует элементы, сколько бы ячеек в ней не было — одна или две, или тысяча.
Неужели ты статику рисуеш?... На дворе 21 век, у всех динамика...
Здравствуйте, PaulMinelly, Вы писали:
PM>Если ты про аяксо-дкомовские хреновины, то это только еще один повод использовать CSS дружище. А не таблицы. Это ж 21 век как ты сказал
Аякс это костыли, призваные сделать из хтмл (пусть и динамического) подобие обычного приложения.
имхо давно пора пересматривать концепцию веб-серверов.
Здравствуйте, Sheridan, Вы писали:
S>Аякс это костыли, призваные сделать из хтмл (пусть и динамического) подобие обычного приложения.
+1
S>имхо давно пора пересматривать концепцию веб-серверов.
Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
Здравствуйте, Дм.Григорьев, Вы писали:
S>>имхо давно пора пересматривать концепцию веб-серверов. ДГ>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.
Здравствуйте, Sheridan, Вы писали:
S>>>имхо давно пора пересматривать концепцию веб-серверов. ДГ>>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш. S>Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.
Чем же это он костыли? И вдвойне непонятно, что можно пересмотреть в HTTransferProtocol? По-моему, он со своей задачей справляется на ура.
S>>имхо давно пора пересматривать концепцию веб-серверов. ДГ>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
Поезд уже уехал. У флэша осталась только ниша streaming content over http (аудио — Pandora, Last.fm; видео — YouTube, Google Video). Потому что со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.
Здравствуйте, Sheridan, Вы писали:
S>>>имхо давно пора пересматривать концепцию веб-серверов. ДГ>>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш. S>Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.
Нет. Проблема в средствах отображения, а не транспорта. Потому HTTP не трогаем.
Здравствуйте, Mamut, Вы писали:
M>Так я тоже не против Но вот не видно этой технологии в обозримом будущем (Тем более, что даже если такая технология появится, переход на нее будет длиться годами)
Потому-что, зачем нам эта новая технология, если все прекрасно можно сделать через JavaScript+HTML+CSS? )
Здравствуйте, gwg-605, Вы писали:
G6>Если стандарт будет помещаться на 10-ти листах, то реализация его будет стоить копейки и понятен он будет значительно большему количеству людей. пример: тот же базовый HTML.
Базовый, это какой версии? Их там около 4-х (: Это ты называешь 10-ю листами?
MBy>>Кстати, мой приятель говорил когда-то, что HTML — это ошибка в корне. Нужно было использовать PostScript (= (просто он в издательском деле работает). G6>Я врагу не пожелаю такого.
В чем-то я с ним согласен. Это реально в наше время. Вспомни PDF. Это ведь и есть PostScript. Но в нем можно хранить и графику, и гиперссылки, и звук. Добавить еще тот же JS (или уже есть?) и получиться хороший переносимый универсальный формат.
MBy>>Не стоит забывать о могучем и страшном словосочетании «обратная совместимость» (; G6>это отмазки. Вспомни OS/2 которая сильно заботилась об обратной совместимости, и где она?
Могу только улыбнуться (: Так говоришь, буд-то это единственная причина ее исчезновения. К тому же, плох тот программер, что не заботиться о обратной совместимости. Не согласен?
G6>Так я о том же, что тот же FONT существует до сих пор, поскольку это была достаточно удачнная идея, которая многим понятна.
Она не удачна. И это многие уже поняли. Потому его и нет в Strict.
M>>Так я тоже не против Но вот не видно этой технологии в обозримом будущем (Тем более, что даже если такая технология появится, переход на нее будет длиться годами)
A>Потому-что, зачем нам эта новая технология, если все прекрасно можно сделать через JavaScript+HTML+CSS? )
Именно. Их надо подровнять всего чуть-чуть. Про CSS я уже говорил
Браузер и так великолепно знает, что такое, например,
#element-id > div.element-class
Но никакого способа воспользоваться этой возможностью у меня нет. Максимум, что я могу сделать — это getElementsByTagName и getElmentById. Почему? Ведь вопросы разработки веб-приложений не ограничиваются этими двумя функциями.
Или.
Браузер неплохо знает, что такое XML + XSLT. А в XSLT вполне свободно используется, например, XPath. Я не знаю, чем отличается XML DOM от HTML DOM с точки зрения браузера.Наверняка ничем Но при этом я не могу написать:
Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.
ДГ>Здравствуйте, Mamut, Вы писали:
M>>со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.
ДГ>Данная ветка является отличной иллюстрацией того, как эта связка "справляется".
Хм. А можно поподробнее?
Для практически идеального сочетания этих технологий уже сейчас нужно всего ничего (а именно это
Здравствуйте, Mamut, Вы писали:
M>Пример. M>Браузер и так великолепно знает, что такое, например, M>
M>#element-id > div.element-class
M>
M>Но никакого способа воспользоваться этой возможностью у меня нет. Максимум, что я могу сделать — это getElementsByTagName и getElmentById. Почему? Ведь вопросы разработки веб-приложений не ограничиваются этими двумя функциями.
Ну вот HTML5 есть функция getElementsByClassName(), конечно не то, что ты хотел, но всё же. В nightly Mozilla её уже реализовали, жди пока остальные подтянутся.
M>Браузер неплохо знает, что такое XML + XSLT. А в XSLT вполне свободно используется, например, XPath. Я не знаю, чем отличается XML DOM от HTML DOM с точки зрения браузера.Наверняка ничем Но при этом я не могу написать: M>
XPath предполагает наличие XML. А ты ведь против XML, забыл? ) И вообще XPath не вписывается в парадигму "JavaScript+HTML+CSS" — это лишняя технология. )
M>Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.
Ну вот предложили они XBL2, которая в частности решает и эту проблему. Впрочем это тоже не вписывается в "JavaScript+HTML+CSS", не будем об этом. )
Здравствуйте, Mamut, Вы писали:
M>>>со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.
ДГ>>Данная ветка является отличной иллюстрацией того, как эта связка "справляется".
M>Хм. А можно поподробнее? M>Для практически идеального сочетания этих технологий уже сейчас нужно всего ничего (а именно это
). А не какая-то сфероконная технология, которой, вдобавок, и не предвидится (уж не от W3C — это точно).
Вторая из ссылок ссылается на то, чего еще нет.
1. На мой взгляд, разработка действительно богатого GUI для тонкого веб-клиента на html/css/js/ajax на порядок (гы, скорее на два) сложнее, чем на flash. Не говоря уже о красоте этого GUI. С каким бы отвращением я не относился к флешу, презентационные сайты и веб-админки для контент-сайтов я предпочитаю делать на нём. (К JavaScript я отношусь с еще большим отвращением — см. пункт 2).
Не то чтобы совсем в тему, но вот мое прошло-воскресное баловство: главное меню для слайд-шоу. Ньюансировка: облака внутри пунктов меню плывут всегда. Когда наводишь мышь, ускоряются в 10 раз и светлеют (при обработке альфа-канала проц грузится под 100%... спрошу-ка я у дядьки Адоба, когда следует ждать 3D-акселлерацию). Бабочка правда малость туповата, но это черновик.
2. Обсуждаемые в этой ветке проблемы в значительной степени связаны с несовместимостью браузеров. Несовместимость эта простилается далеко за пределы визуальной модели. Работа с DOM, например, — тоже была песня. И флешеру тут баааальшое щастье.
Хотел ещё сказать про трафик. Но понял, что мне могут совершенно справедливо указать на связку ajax + gzip. Хотя все равно не покидает ощущение, что суммарный объем html+css+js кода будет больше чем аналогичный swf — все-таки компиляция+сжатие должно дать лучший эффект, чем просто сжатие.
У флеша, тем не менее, существует как минимум один юзабилити-косяк: он не позволяет мне открывать страницы средним кликом мыши в других вкладках файрфокса. Но для веб-приложения, сделанного на окошках, открытие окошка в отдельной вкладке смысла не имеет. (Кстати, вопросы с закладками и историей браузера решаются на флеше так же, как и в ajax-приложениях: с помощью url hash.)
P.S. Флейм по делу привествуется — может, я-таки выкрою время на статью про флеш 9, и сравнение с ajax там будет не лишним.
У меня складывается ощущение, что ты смешиваешь уровни. Какова конечная цель? Лабать динамические сайты... Нет, даже не так. Цель — лабать тонкие функциональные веб-клиенты. Динамические веб-сайты — это уже вариант реализации. А твои мечты о прикручивании XPath к и без того уже немаленькой группе технологий — это уже вариант реализации реализации. То бишь вообще детали реализации.
[привет Сергею Губанову с Обероном и Владу с Немерле]
В то же время, тот же Flash (и в еще большей степени — Flex) позволяет лабать интерфейсы на гораздо более высоком уровне абстракции — на уровне, скажем, соизмеримом с редактором форм Delphi. По сравнению с флешем, вся эта возня вокруг недоделанных HTML+JS+CSS напоминает то ли попытки написать Янус на ассемблере
Здравствуйте, PaulMinelly, Вы писали:
PM>По поводу того, почему народ пытается использовать divы, а не таблицы или еще что. PM>Причина — одна. ПОтому что это CSS-совместимо, а значит можно изменить всю раскладку страницы, просто поменяв один CSS-стиль. Все. Таблица — она фиксирует элементы, сколько бы ячеек в ней не было — одна или две, или тысяча. PM>Все что верстается таблицей — может быть сверстано дивами. Даже таблица в N строк и M столбцов. Один гемор у этого всего только, что нельзя нормально выровнять ПО ВЫСОТЕ внутри блока div так чтобы это смотрелось одинакого во всех брайзерах. Приходится прибегать с различного рода кросс-браузерным хакам. Вот это настоящий гемор. А все остальное — это просто почти сказка. Почти.
Если че вдруг кому интересно — вот симпотичные костыли
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Если программист в рабочее время играет, значит —
либо у него мало работы и большая зарплата,
либо у него много работы и маленькая зарплата.
имхо1. Здесь примерно как люди переходят от paint'а к фотошопу. Вначале все рисуют в плоскости, а потом привыкают к слоям.
имхо2. блочная верстка — как наркота. Как только я немного научился — не могу отвыкнуть. Эстетически чертовски приятно, хотя если бы мог — часто бы юзал табличную верстку (время бы сокращало) — но нет. Искусство требует жертв.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Если программист в рабочее время играет, значит —
либо у него мало работы и большая зарплата,
либо у него много работы и маленькая зарплата.
ДГ>У флеша, тем не менее, существует как минимум один юзабилити-косяк: он не позволяет мне открывать страницы средним кликом мыши в других вкладках файрфокса. Но для веб-приложения, сделанного на окошках, открытие окошка в отдельной вкладке смысла не имеет. (Кстати, вопросы с закладками и историей браузера решаются на флеше так же, как и в ajax-приложениях: с помощью url hash.)
У флеша еще есть другой косяк по-круче чем средний клик мышью. Это правый клик. Остается только рабочий левый. А как известно с одним кликом можно только на маке жить.
Поэтому я флеш уже хотя бы по этому не перевариваю + страница не скроллится, флешевый искусственный скроллинг тормозит. Поддержка колеса — надо выкручиваться и вебмастера по этому ее не делают. В результате, я как пользователь все время вижу эти грабли. Правый клик тоже никто не делает, потому что на нем дургая дурацкая функциональность и страдаю от этого я, не могу открыть ссылку в новом окне. И вообще многая браузерная функциональность, к которой привык — во флеше идет лесом. Вообщем по сравнению с javascript + css, флеш — это гемор. Но конечно красиво.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Mamut, Вы писали:
M>>Пример. M>>Браузер и так великолепно знает, что такое, например, M>>
M>>#element-id > div.element-class
M>>
M>>Но никакого способа воспользоваться этой возможностью у меня нет. Максимум, что я могу сделать — это getElementsByTagName и getElmentById. Почему? Ведь вопросы разработки веб-приложений не ограничиваются этими двумя функциями.
A>Ну вот HTML5 есть функция getElementsByClassName(), конечно не то, что ты хотел, но всё же. В nightly Mozilla её уже реализовали, жди пока остальные подтянутся.
Это совсем не то CSS предполагает гораздо более гибкую выборку элементов, чем только по ID и по ClassName. Один только "#element-id > div.element-class" чего стоит.
A>XPath предполагает наличие XML. А ты ведь против XML, забыл? ) И вообще XPath не вписывается в парадигму "JavaScript+HTML+CSS" — это лишняя технология. )
Я не против XML Я против того, что его прикручивают туда, куда не надо, и не прикручивают туда, куда надо
Я, правда, так и не понял, чем HTML DOM отличается от XML DOM? И какие сложности в реализации XPath поверх HTML DOM?
M>>Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.
A>Ну вот предложили они XBL2, которая в частности решает и эту проблему. Впрочем это тоже не вписывается в "JavaScript+HTML+CSS", не будем об этом. )
Ключевое слово — в частности. И XBL никогда реализован не будет (никогда — это в ближайшие лет 10). Причина описана здесь
Вопрос. Уже в который раз задаю, но ответа так и не получил
Зачем нужна новая технология, которая:
а) не дает ничего нового
б) не облегчает решение описанных мной выше задач ни на йоту
с) будет по-разному реализована в разных браузерах (если будет) и все равно будет вызывать кучу проблем для разработчиков
d) ничем не отличается от существующей связки JavaScript + CSS + HTML?
Итак, привязка только к id элемента. Завязка на неизвестный xul, который будет только у Мозиллы, но не будет у Оперы, ИЕ, Сафари и т.п.
Пример реализации того же уже существующими методами:
// используется библиотека jQuery, http://jquery.com/
$("#searchbar-box").append("<input type=\"button\" class=\"search-go-button\">");
/*
Можно было выбрать похитрее. Например:
$("#searchbar-box > div:nth-child(odd)")...
Если не нравится использовать "<input type=\"button\" class=\"search-go-button\">"
то с версии 1.1 с jQuery можно будет использовать [url=http://www.yui-ext.com/deploy/yui-ext/docs/]YUI Ext[/url]
*/
Мне и сто лет не нужен XBL, если из-за него мне придется писать в 5-6 раз больше кода для достижения тех же результатов.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, Mamut, Вы писали:
ДГ>[злостно поскипано про XPath]
ДГ>У меня складывается ощущение, что ты смешиваешь уровни. Какова конечная цель? Лабать динамические сайты... Нет, даже не так. Цель — лабать тонкие функциональные веб-клиенты. Динамические веб-сайты — это уже вариант реализации. А твои мечты о прикручивании XPath к и без того уже немаленькой группе технологий — это уже вариант реализации реализации. То бишь вообще детали реализации.
ДГ>[привет Сергею Губанову с Обероном и Владу с Немерле]
ДГ>В то же время, тот же Flash (и в еще большей степени — Flex) позволяет лабать интерфейсы на гораздо более высоком уровне абстракции — на уровне, скажем, соизмеримом с редактором форм Delphi. По сравнению с флешем, вся эта возня вокруг недоделанных HTML+JS+CSS напоминает то ли попытки написать Янус на ассемблере
Эээ нет. Во-первых, Флэш — это 7 версия, не больше. Opera под Линукс до сих пор версию выше 7-й не поддерживает (или у меня просто руки кривые ). Поэтому все ограничивается 7й версией. Со всеми вытекажщими.
Во-вторых, имхо, для разработки _грамотного_ интерфейса на флэше требуется, более высокая квалификация, чем для для написания оного же в HTML + CSS + Javascript (я не говорю о Liquid Three-Column Layout Можно и таблицами пользоваться )
Ну и не забываем, что Flash — это 699$, что никак не может сравниться со стоимостью HTML+CSS+Javascript
Здравствуйте, Mamut, Вы писали:
ДГ>>В то же время, тот же Flash (и в еще большей степени — Flex) позволяет лабать интерфейсы на гораздо более высоком уровне абстракции — на уровне, скажем, соизмеримом с редактором форм Delphi. По сравнению с флешем, вся эта возня вокруг недоделанных HTML+JS+CSS напоминает то ли попытки написать Янус на ассемблере
, то ли добровольный мазохизм бета-тестера.
M>Эээ нет. Во-первых, Флэш — это 7 версия, не больше. Opera под Линукс до сих пор версию выше 7-й не поддерживает (или у меня просто руки кривые ). Поэтому все ограничивается 7й версией. Со всеми вытекажщими.
Насчет оперы под линухом не знаю, а опера под виндой, так же как и все остальные браузеры, при необходимости обновляет плагин автоматом.
M>Во-вторых, имхо, для разработки _грамотного_ интерфейса на флэше требуется, более высокая квалификация, чем для для написания оного же в HTML + CSS + Javascript (я не говорю о Liquid Three-Column Layout Можно и таблицами пользоваться )
А я говорю не про частности типа layouts, а про суммарную сложность разработки средних и крупных Ajax-приложений. Тот же gmail, по моему субъективному ощущению, на флеше сделать на порядок проще.
M>Ну и не забываем, что Flash — это 699$, что никак не может сравниться со стоимостью HTML+CSS+Javascript
Ну, за удобство RAD надо платить. Хотя, во-первых, $700 это горааааздо ниже стоимости тех же дельфей (откровенно говоря, смешная стоимость). А во-вторых, Flex SDK бесплатен, т.е. платим только если хотим визуальный дизайнер форм, без которого, вообще говоря, при желании вполне можно и прожить — исходный XML-формат достаточно простой и компактный.
Здравствуйте, Mamut, Вы писали:
A>>XPath предполагает наличие XML. А ты ведь против XML, забыл? ) И вообще XPath не вписывается в парадигму "JavaScript+HTML+CSS" — это лишняя технология. ) M>Я не против XML Я против того, что его прикручивают туда, куда не надо, и не прикручивают туда, куда надо M>Я, правда, так и не понял, чем HTML DOM отличается от XML DOM? И какие сложности в реализации XPath поверх HTML DOM?
Для DOM1 и DOM2 DOM HTML это такая надстройка над DOM Core. В остальном это была шутка.
M>>>Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.
M>Зачем нужна новая технология, которая: M>а) не дает ничего нового M>б) не облегчает решение описанных мной выше задач ни на йоту M>с) будет по-разному реализована в разных браузерах (если будет) и все равно будет вызывать кучу проблем для разработчиков M>d) ничем не отличается от существующей связки JavaScript + CSS + HTML?
a) даёт
b) твоими задачами проблемы не исчерпываются
c) домыслы
d) дополняет
К спору в "Философии" я еще вернусь чуть позже, как дел поубавится.
M>Это сравнение я уже приводил: M>
M>Итак, привязка только к id элемента. Завязка на неизвестный xul, который будет только у Мозиллы, но не будет у Оперы, ИЕ, Сафари и т.п.
Нет привязки к идентификатору элемента, тот идентификатор, что ты выделил, является идентификатором байндинга и служит для отличия нескольких байиндингов в одном файле, а также для обращения к конкретному байндингу.
Здравствуйте, Mamut, Вы писали:
M>Эээ нет. Во-первых, Флэш — это 7 версия, не больше. Opera под Линукс до сих пор версию выше 7-й не поддерживает (или у меня просто руки кривые ). Поэтому все ограничивается 7й версией. Со всеми вытекажщими.
У мну на 64битном генту у файрфокса и конкверора 9й флеш...
A>>>XPath предполагает наличие XML. А ты ведь против XML, забыл? ) И вообще XPath не вписывается в парадигму "JavaScript+HTML+CSS" — это лишняя технология. ) M>>Я не против XML Я против того, что его прикручивают туда, куда не надо, и не прикручивают туда, куда надо M>>Я, правда, так и не понял, чем HTML DOM отличается от XML DOM? И какие сложности в реализации XPath поверх HTML DOM?
A>Для DOM1 и DOM2 DOM HTML это такая надстройка над DOM Core. В остальном это была шутка.
Так что мешает реализовать XPath поверх HTML DOM?
M>>>>Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.
M>>Зачем нужна новая технология, которая: M>>а) не дает ничего нового M>>б) не облегчает решение описанных мной выше задач ни на йоту M>>с) будет по-разному реализована в разных браузерах (если будет) и все равно будет вызывать кучу проблем для разработчиков M>>d) ничем не отличается от существующей связки JavaScript + CSS + HTML?
A>a) даёт
Например?
A>b) твоими задачами проблемы не исчерпываются
Но мне нужно решение конкретно моих задач
A>c) домыслы
Не домыслы. За 10 лет CSS не реализовали. А тут абсолютно новая технология (хоть и на 90% повторяющая старые)
A>d) дополняет
Чем?
A>К спору в "Философии" я еще вернусь чуть позже, как дел поубавится.
M>>Итак, привязка только к id элемента. Завязка на неизвестный xul, который будет только у Мозиллы, но не будет у Оперы, ИЕ, Сафари и т.п.
A>Нет привязки к идентификатору элемента, тот идентификатор, что ты выделил, является идентификатором байндинга и служит для отличия нескольких байиндингов в одном файле, а также для обращения к конкретному байндингу. A>
A>#searchbar-box > div:nth-child(odd) {
A> -moz-binding: url("/path/to/binding.xml#searchbar-box");
A>}
A>
Сорри. Действительно забыл об этом Тогда вопрос уходит в зрительный зал То есть к c-smile и behaviors. Я лично тоже не понимаю, зачем там XML. И не вижу, чем оно отличается от текущего unobtrusive Javascript...
A>Нет завязки на XUL, байндинг работает и в XHTML: http://rsdn.ru/Forum/?mid=2142648
Opera Watch: Are there any plans to support Mozilla’s XUL API? If not, why?
Opera: No current plans to support XUL. Opera for desktop is built on top of our own cross-platform “Quick” GUI tool kit , where Mozilla/Firefox uses their XUL.
M>>Эээ нет. Во-первых, Флэш — это 7 версия, не больше. Opera под Линукс до сих пор версию выше 7-й не поддерживает (или у меня просто руки кривые ). Поэтому все ограничивается 7й версией. Со всеми вытекажщими.
ДГ>Насчет оперы под линухом не знаю, а опера под виндой, так же как и все остальные браузеры, при необходимости обновляет плагин автоматом.
Воот. А под Линуксом с флэшем проблемы. 9-я версия флэша под Линукс вышла только очень недавно.
M>>Во-вторых, имхо, для разработки _грамотного_ интерфейса на флэше требуется, более высокая квалификация, чем для для написания оного же в HTML + CSS + Javascript (я не говорю о Liquid Three-Column Layout Можно и таблицами пользоваться )
ДГ>А я говорю не про частности типа layouts, а про суммарную сложность разработки средних и крупных Ajax-приложений. Тот же gmail, по моему субъективному ощущению, на флеше сделать на порядок проще.
А я именно про layouts и говорю Кстати, что-то я не видел приложений по уровню равных тому же ГМылу. Кроссбраузерных и кроссплатформенных
M>>Ну и не забываем, что Flash — это 699$, что никак не может сравниться со стоимостью HTML+CSS+Javascript
ДГ>Ну, за удобство RAD надо платить. Хотя, во-первых, $700 это горааааздо ниже стоимости тех же дельфей (откровенно говоря, смешная стоимость).
Ага. Для студента/школьника, который только-только с вебом знакомится Хотя это как бы не проблема из-за этого:
ДГ>А во-вторых, Flex SDK бесплатен, т.е. платим только если хотим визуальный дизайнер форм, без которого, вообще говоря, при желании вполне можно и прожить — исходный XML-формат достаточно простой и компактный.
Ну, с таким ХМЛ-ем как бы даже можно жить :
<?xml version="1.0"encoding="utf-8"?>
<!-- ?xml tag must start in line 1 column 1 -->
<!-- MXML root element tag -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
// Define an ActionScript function.
private function duplicate():void {
myText.text=myInput.text;
}
]]>
</mx:Script>
<!-- Flex controls exist in a container. Define a Panel container. -->
<mx:Panel title="My Application">
<!-- TextInput control for user input. -->
<mx:TextInput id="myInput" width="150" text=""/>
<!-- Output TextArea control. -->
<mx:TextArea id="myText" text="" width="150"/>
<!-- Button control that triggers the copy. -->
<mx:Button id="myButton" label="Copy Text"
click="duplicate();"/>
</mx:Panel>
</mx:Application>
Хотя непонятно, насколько это все расширяемо...
ЗЫ. Flex... XUL... XAML... ЫЫЫЫ И все с ХМЛем... И выглядят все, как братья близнецы...
M>>Эээ нет. Во-первых, Флэш — это 7 версия, не больше. Opera под Линукс до сих пор версию выше 7-й не поддерживает (или у меня просто руки кривые ). Поэтому все ограничивается 7й версией. Со всеми вытекажщими. S>У мну на 64битном генту у файрфокса и конкверора 9й флеш...
У них — без проблем. А вот Опера обновлять не хочет... А так как Opera — это браузер категории А, то волей-неволей надо подерживать и его. Что исключает, напримре, тот же Flex (который требует Flash 9, если мне не изменяет память)
Здравствуйте, Mamut, Вы писали:
M>Так что мешает реализовать XPath поверх HTML DOM?
То, что XPath это DOM3, и ждать тебе его ещё 10 лет. )
A>>a) даёт M>Например? A>>b) твоими задачами проблемы не исчерпываются M>Но мне нужно решение конкретно моих задач A>>c) домыслы M>Не домыслы. За 10 лет CSS не реализовали. А тут абсолютно новая технология (хоть и на 90% повторяющая старые) A>>d) дополняет M>Чем?
А это, как и обещал, позже. )
A>>Opera, кстати, заявляла что-то про поддержку XUL. M>Единственное, что я нашел — это интервью 30 января 2005 года: M>То есть пункт с) остается в силе
Здравствуйте, Mamut, Вы писали:
M>А я именно про layouts и говорю Кстати, что-то я не видел приложений по уровню равных тому же ГМылу. Кроссбраузерных и кроссплатформенных
Вот, впрочем, еще примерчик: онлайновая тусовка американских китайцев (знакомства, блоги и т.п.): http://cliqueclique.com/
Клиента делал человек, ОЧЕНЬ далекий от программирования, наверное поэтому дизайн такой убогий. И тем не менее, работает. А за серверную сторону мне не стыдно... почти.
Большинство сайтов производителей джинсов сделано тоже целиком на флеше. Это тоже всё презентационные сайты, практически веб-приложения.
С годик назад видел настоящий контент-портал, выполненный в чистом информационном стиле, но с многоуровневыми popup-меню. Найти ссылку, увы, уже наверное не смогу. В любом случае, мне думается, что чистый информационный дизайн лучше делать безо всякой динамики вообще, на голом HTML+CSS.
Ну а насчет кроссплатформенности и кроссбраузерности я твоей иронии вообще не понимаю. Геморрой случается вокруг необходимости взаимодействия с браузером для корректной обработки URL hash. Никаких других проблем с кроссплатформенностью и кроссбраузерностью я не видел — и не слышал. И, честно говоря, сильно удивлюсь, если услышу. А то, что Player 9 для линукса только появился — дык и сам Flash Pro 9 IDE пока еще в стадии беты. Не вижу ничего предосудительного в том, что они релизят вещи по мере готовности, а не тянут время, чтобы зарелизить все сразу.
Здравствуйте, Mamut, Вы писали:
M>У них — без проблем. А вот Опера обновлять не хочет... А так как Opera — это браузер категории А, то волей-неволей надо подерживать и его. Что исключает, напримре, тот же Flex (который требует Flash 9, если мне не изменяет память)
Я всегда говорил, что опера — г****. Они даже XSLT удосужились встроить только в девятой версии — в тот самый момент, когда стало ясно, что этот XSLT в недалеком будущем никому нафиг не нужен будет (потому что появился XQuery). В итоге, весьма неплохая технология оптимизации трафика (причем грамотной оптимизации: наивысший уровень разделения данных и представления) так и осталась не у дел.
ДГ>Ну а насчет кроссплатформенности и кроссбраузерности я твоей иронии вообще не понимаю. Геморрой случается вокруг необходимости взаимодействия с браузером для корректной обработки URL hash. Никаких других проблем с кроссплатформенностью и кроссбраузерностью я не видел — и не слышал. И, честно говоря, сильно удивлюсь, если услышу. А то, что Player 9 для линукса только появился — дык и сам Flash Pro 9 IDE пока еще в стадии беты. Не вижу ничего предосудительного в том, что они релизят вещи по мере готовности, а не тянут время, чтобы зарелизить все сразу.
Flash 8 тогда
У меня в Опере 9.2 под линуксом — версия 7. Поэтому, увы, из приведенных ссылок я увидел только одну — сайт форда.
Ну, я их конечно увидел, в FF Но проблема кроссбраузерности остается. И, к моему удивлению, именно у флэша — а ведь это действительно была кросс(браузер+платформа) система.
Здравствуйте, Mamut, Вы писали:
M>>>Так что мешает реализовать XPath поверх HTML DOM? A>>То, что XPath это DOM3, и ждать тебе его ещё 10 лет. ) M>Почему же jQuery XPath реализует, а браузеры не могут?
M>>У них — без проблем. А вот Опера обновлять не хочет... А так как Opera — это браузер категории А, то волей-неволей надо подерживать и его. Что исключает, напримре, тот же Flex (который требует Flash 9, если мне не изменяет память)
ДГ>Я всегда говорил, что опера — г****. Они даже XSLT удосужились встроить только в девятой версии — в тот самый момент, когда стало ясно, что этот XSLT в недалеком будущем никому нафиг не нужен будет (потому что появился XQuery). В итоге, весьма неплохая технология оптимизации трафика (причем грамотной оптимизации: наивысший уровень разделения данных и представления) так и осталась не у дел.
Хм. Опера не реализовали технологию, которая и так оказалась не у дел и поэтому этот браузер — г..? Интересные подходы
Но эту ветку — про Оперу — можно выделять и сносить в КСВ
О. Вот это я и имел в виду!
A>>>Кстати, нашёл интересную штуку — DHTML XUL interpreter for IE5+, Opera7+: http://wednus.com/wednus0.3.4/doc/samples/DXULi.php M>>Костыль к (практически несуществующей) технологии с непонятными бенефитами Но так как про бенефиты мы еще не говорили, пока молчу
A>Да не спорю, что костыль, просто наткнулся случайно, решил поделиться.
Здравствуйте, Mamut, Вы писали:
M>Хм. Опера не реализовали технологию, которая и так оказалась не у дел и поэтому этот браузер — г..? Интересные подходы M>Но эту ветку — про Оперу — можно выделять и сносить в КСВ
В КСВ подобных веток уже достаточно. И в них наверняка можно найти и другие косяки оперы (в том числе, если память не изменяет, и в моих постах).
И кстати, к вопросу о флеш9 плагине: виноват адоб или опера?
M>>Хм. Опера не реализовали технологию, которая и так оказалась не у дел и поэтому этот браузер — г..? Интересные подходы M>>Но эту ветку — про Оперу — можно выделять и сносить в КСВ
ДГ>В КСВ подобных веток уже достаточно. И в них наверняка можно найти и другие косяки оперы (в том числе, если память не изменяет, и в моих постах).
Все равно ее не брошу, потому что она хорошая
ДГ>И кстати, к вопросу о флеш9 плагине: виноват адоб или опера?
Здравствуйте, MBy, Вы писали:
MBy>Здравствуйте, Аноним, Вы писали:
А>>>>http://www.webstandards.org/act/acid2/test.html А>>Впрочем, ссылка это просто иллюстрация неподготовленности браузеров к стандартам CSS. MBy>Чушь! Этот тест и сам не проходит валидации по CSS.
В стандарте СSS еще и ошибки специфицированы. И собно браузеры должны и их правильно(по спецификации) хендлить, тока тогда картинка будет нормальной.
Здравствуйте, PaulMinelly, Вы писали:
PM>По поводу того, почему народ пытается использовать divы, а не таблицы или еще что. PM>Причина — одна. ПОтому что это CSS-совместимо, а значит можно изменить всю раскладку страницы, просто поменяв один CSS-стиль. Все. Таблица — она фиксирует элементы, сколько бы ячеек в ней не было — одна или две, или тысяча.
А Асп.Нет есть такая штука мастерпейдж называеться. Это как караз единое место где храниться лаяут. Тоесть фактически для того чтобы поменять лаяут на всем сайте достатоно его поменять тока в одном мастепейдже.
.
) было написано, что для полного познания CSS требуется год, а то и два 
Они что, с ума посходили?
Строить страницы с CSS гораздо легче, но... только в теории, а не в этой жизни. CSS браузеры поддерживают из рук вон плохо. 
Но там какой-то хак для ИЕ
В итоге, весьма неплохая технология оптимизации трафика (причем грамотной оптимизации: наивысший уровень разделения данных и представления) так и осталась не у дел.
