Re: div vs table - Веб программирование

Re[3]: А где самый главный ответ?

	От:	Sheridan
	Дата:	12.03.07 04:30
	Оценка:

Здравствуйте, PaulMinelly, Вы писали:

PM>Если ты про аяксо-дкомовские хреновины, то это только еще один повод использовать CSS дружище. А не таблицы. Это ж 21 век как ты сказал

Аякс это костыли, призваные сделать из хтмл (пусть и динамического) подобие обычного приложения.
имхо давно пора пересматривать концепцию веб-серверов.

[RSDN@Home][1.2.0][alpha r.676]

Matrix has you...

Re[4]: А где самый главный ответ?

	От:	Дм.Григорьев
	Дата:	12.03.07 05:11
	Оценка:

Здравствуйте, Sheridan, Вы писали:

S>Аякс это костыли, призваные сделать из хтмл (пусть и динамического) подобие обычного приложения.
+1

S>имхо давно пора пересматривать концепцию веб-серверов.
Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re[5]: А где самый главный ответ?

	От:	Sheridan
	Дата:	12.03.07 05:29
	Оценка:

Здравствуйте, Дм.Григорьев, Вы писали:

S>>имхо давно пора пересматривать концепцию веб-серверов.
ДГ>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.

[RSDN@Home][1.2.0][alpha r.676]

Matrix has you...

Re[6]: А где самый главный ответ?

	От:	Дм.Григорьев
	Дата:	12.03.07 05:37
	Оценка:

Здравствуйте, Sheridan, Вы писали:

S>>>имхо давно пора пересматривать концепцию веб-серверов.
ДГ>>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
S>Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.

Чем же это он костыли? И вдвойне непонятно, что можно пересмотреть в HTTransferProtocol? По-моему, он со своей задачей справляется на ура.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re[5]: А где самый главный ответ?

От:	Mamut	http://dmitriid.com
Дата:	12.03.07 07:40
Оценка:

S>>имхо давно пора пересматривать концепцию веб-серверов.
ДГ>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.

Поезд уже уехал. У флэша осталась только ниша streaming content over http (аудио — Pandora, Last.fm; видео — YouTube, Google Video). Потому что со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.

dmitriid.com … GitHub … LinkedIn

Re[6]: А где самый главный ответ?

	От:	Дм.Григорьев
	Дата:	12.03.07 13:20
	Оценка:

Здравствуйте, Mamut, Вы писали:

M>со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.

Данная ветка является отличной иллюстрацией того, как эта связка "справляется".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re[6]: А где самый главный ответ?

От:	anonymous	http://denis.ibaev.name/
Дата:	12.03.07 13:31
Оценка:	+1

Здравствуйте, Sheridan, Вы писали:

S>>>имхо давно пора пересматривать концепцию веб-серверов.
ДГ>>Скорее, тонких веб-клиентов. Которую уже на самом деле пересмотрели: все дружно изучаем флеш.
S>Флеш... Это конечно более прямые и правильные, но имхо всетаки тоже костыли. Тут скорее надо пересматривать/дополнять сам http протокол.

Нет. Проблема в средствах отображения, а не транспорта. Потому HTTP не трогаем.

Re[12]: div vs table

От:	anonymous	http://denis.ibaev.name/
Дата:	12.03.07 13:34
Оценка:

Здравствуйте, Mamut, Вы писали:

M>Так я тоже не против

Но вот не видно этой технологии в обозримом будущем

(Тем более, что даже если такая технология появится, переход на нее будет длиться годами)

Потому-что, зачем нам эта новая технология, если все прекрасно можно сделать через JavaScript+HTML+CSS? )

Re[9]: div vs table

От:	MBy	http://maxim.vuets.name/
Дата:	12.03.07 14:39
Оценка:

Здравствуйте, gwg-605, Вы писали:

G6>Если стандарт будет помещаться на 10-ти листах, то реализация его будет стоить копейки и понятен он будет значительно большему количеству людей. пример: тот же базовый HTML.
Базовый, это какой версии? Их там около 4-х (: Это ты называешь 10-ю листами?

MBy>>Кстати, мой приятель говорил когда-то, что HTML — это ошибка в корне. Нужно было использовать PostScript (= (просто он в издательском деле работает).
G6>Я врагу не пожелаю такого.
В чем-то я с ним согласен. Это реально в наше время. Вспомни PDF. Это ведь и есть PostScript. Но в нем можно хранить и графику, и гиперссылки, и звук. Добавить еще тот же JS (или уже есть?) и получиться хороший переносимый универсальный формат.

MBy>>Не стоит забывать о могучем и страшном словосочетании «обратная совместимость» (;
G6>это отмазки. Вспомни OS/2 которая сильно заботилась об обратной совместимости, и где она?
Могу только улыбнуться (: Так говоришь, буд-то это единственная причина ее исчезновения. К тому же, плох тот программер, что не заботиться о обратной совместимости. Не согласен?

G6>Так я о том же, что тот же FONT существует до сих пор, поскольку это была достаточно удачнная идея, которая многим понятна.
Она не удачна. И это многие уже поняли. Потому его и нет в Strict.

Hoc est simplicissimum!

Re[13]: div vs table

От:	Mamut	http://dmitriid.com
Дата:	12.03.07 15:06
Оценка:	+1

M>>Так я тоже не против

Но вот не видно этой технологии в обозримом будущем

(Тем более, что даже если такая технология появится, переход на нее будет длиться годами)

A>Потому-что, зачем нам эта новая технология, если все прекрасно можно сделать через JavaScript+HTML+CSS? )

Именно. Их надо подровнять всего чуть-чуть. Про CSS я уже говорил. А JavaScript...

Пример.

Браузер и так великолепно знает, что такое, например,

#element-id > div.element-class

Но никакого способа воспользоваться этой возможностью у меня нет. Максимум, что я могу сделать — это getElementsByTagName и getElmentById. Почему?

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

Или.

Браузер неплохо знает, что такое XML + XSLT. А в XSLT вполне свободно используется, например, XPath. Я не знаю, чем отличается XML DOM от HTML DOM с точки зрения браузера.Наверняка ничем

Но при этом я не могу написать:

getElementsByXPath("/html/body//p")
getElementsByXPath("/*/body//p")
getElementsByXPath("//p/../div")

Почему?

У меня, например, вполне себе встречается:

$("item[@type='description']")...;
$(".ex").click(...);

А в примерах типа этого встречаются:

$"input[@type='radio'] + label")...
$("#greenbox .overfull")...
$("form #postopt input[@name='basichtml']")...

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

dmitriid.com … GitHub … LinkedIn

Re[7]: А где самый главный ответ?

От:	Mamut	http://dmitriid.com
Дата:	12.03.07 15:15
Оценка:

ДГ>Здравствуйте, Mamut, Вы писали:

M>>со всем остальным также (и — быстрее!) справляется связка JavaScript + HTML + CSS.

ДГ>Данная ветка является отличной иллюстрацией того, как эта связка "справляется".

Хм. А можно поподробнее?

Для практически идеального сочетания этих технологий уже сейчас нужно всего ничего (а именно это и это). А не какая-то сфероконная технология, которой, вдобавок, и не предвидится (уж не от W3C — это точно).

dmitriid.com … GitHub … LinkedIn

Re[14]: div vs table

От:	anonymous	http://denis.ibaev.name/
Дата:	12.03.07 15:44
Оценка:

Здравствуйте, 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>

M>getElementsByXPath("/html/body//p")
M>getElementsByXPath("/*/body//p")
M>getElementsByXPath("//p/../div")
M>

Почему?

XPath предполагает наличие XML. А ты ведь против XML, забыл? ) И вообще XPath не вписывается в парадигму "JavaScript+HTML+CSS" — это лишняя технология. )

M>Вопрос. Вместо того, чтобы ввести буквально два с половиной изменения в существующие технологии, w3c пердлагает что? Да ничего они не предлагают. Во всяком случае, ничего из того, что могло бы решить описанные проблемы.

Ну вот предложили они XBL2, которая в частности решает и эту проблему. Впрочем это тоже не вписывается в "JavaScript+HTML+CSS", не будем об этом. )

Re[8]: А где самый главный ответ?

	От:	Дм.Григорьев
	Дата:	12.03.07 16:24
	Оценка:

Здравствуйте, 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 там будет не лишним.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re[14]: div vs table

	От:	Дм.Григорьев
	Дата:	12.03.07 19:23
	Оценка:

Здравствуйте, Mamut, Вы писали:

[злостно поскипано про XPath]

У меня складывается ощущение, что ты смешиваешь уровни. Какова конечная цель? Лабать динамические сайты... Нет, даже не так. Цель — лабать тонкие функциональные веб-клиенты. Динамические веб-сайты — это уже вариант реализации. А твои мечты о прикручивании XPath к и без того уже немаленькой группе технологий — это уже вариант реализации реализации. То бишь вообще детали реализации.

[привет Сергею Губанову с Обероном и Владу с Немерле]

В то же время, тот же Flash (и в еще большей степени — Flex) позволяет лабать интерфейсы на гораздо более высоком уровне абстракции — на уровне, скажем, соизмеримом с редактором форм Delphi. По сравнению с флешем, вся эта возня вокруг недоделанных HTML+JS+CSS напоминает то ли попытки написать Янус на ассемблере, то ли добровольный мазохизм бета-тестера.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re: А где самый главный ответ?

От:	kost-BebiX	http://fedorastones.blogspot.com
Дата:	13.03.07 00:32
Оценка:

Здравствуйте, PaulMinelly, Вы писали:

PM>По поводу того, почему народ пытается использовать divы, а не таблицы или еще что.
PM>Причина — одна. ПОтому что это CSS-совместимо, а значит можно изменить всю раскладку страницы, просто поменяв один CSS-стиль. Все. Таблица — она фиксирует элементы, сколько бы ячеек в ней не было — одна или две, или тысяча.
PM>Все что верстается таблицей — может быть сверстано дивами. Даже таблица в N строк и M столбцов. Один гемор у этого всего только, что нельзя нормально выровнять ПО ВЫСОТЕ внутри блока div так чтобы это смотрелось одинакого во всех брайзерах. Приходится прибегать с различного рода кросс-браузерным хакам. Вот это настоящий гемор. А все остальное — это просто почти сказка. Почти.

Если че вдруг кому интересно — вот симпотичные костыли

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Re[2]: А где самый главный ответ?

От:	kost-BebiX	http://fedorastones.blogspot.com
Дата:	13.03.07 00:33
Оценка:	5 (1)

Здравствуйте, kost-BebiX, Вы писали:

KB>Если че вдруг кому интересно — вот симпотичные костыли

Sorry. А вот и они:
http://www.jakpsatweb.cz/css/css-vertical-center-solution.html

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Re: div vs table

От:	kost-BebiX	http://fedorastones.blogspot.com
Дата:	13.03.07 00:40
Оценка:	+1

Здравствуйте, Sheridan, Вы писали:

[скип]

имхо1. Здесь примерно как люди переходят от paint'а к фотошопу. Вначале все рисуют в плоскости, а потом привыкают к слоям.
имхо2. блочная верстка — как наркота. Как только я немного научился — не могу отвыкнуть. Эстетически чертовски приятно, хотя если бы мог — часто бы юзал табличную верстку (время бы сокращало) — но нет. Искусство требует жертв.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Re[9]: А где самый главный ответ?

	От:	PaulMinelly
	Дата:	13.03.07 03:40
	Оценка:	+3

ДГ>У флеша, тем не менее, существует как минимум один юзабилити-косяк: он не позволяет мне открывать страницы средним кликом мыши в других вкладках файрфокса.

Но для веб-приложения, сделанного на окошках, открытие окошка в отдельной вкладке смысла не имеет. (Кстати, вопросы с закладками и историей браузера решаются на флеше так же, как и в ajax-приложениях: с помощью url hash.)

У флеша еще есть другой косяк по-круче чем средний клик мышью. Это правый клик. Остается только рабочий левый. А как известно с одним кликом можно только на маке жить.
Поэтому я флеш уже хотя бы по этому не перевариваю + страница не скроллится, флешевый искусственный скроллинг тормозит. Поддержка колеса — надо выкручиваться и вебмастера по этому ее не делают. В результате, я как пользователь все время вижу эти грабли. Правый клик тоже никто не делает, потому что на нем дургая дурацкая функциональность и страдаю от этого я, не могу открыть ссылку в новом окне. И вообще многая браузерная функциональность, к которой привык — во флеше идет лесом. Вообщем по сравнению с javascript + css, флеш — это гемор. Но конечно красиво.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Re[15]: div vs table

От:	Mamut	http://dmitriid.com
Дата:	13.03.07 07:36
Оценка:

Здравствуйте, 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?

Это сравнение я уже приводил:

<binding id="searchbar-box">
  <content>
    <children/>
    <xul:stack class="search-go-button-stack">
      <xul:toolbarbutton class="search-go-button" label="&search.button.go.label;"/>
    </xul:stack>
  </content>
</binding>

Итак, привязка только к 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 раз больше кода для достижения тех же результатов.

dmitriid.com … GitHub … LinkedIn

Re[15]: div vs table

От:	Mamut	http://dmitriid.com
Дата:	13.03.07 08:13
Оценка:

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Здравствуйте, 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

dmitriid.com … GitHub … LinkedIn

|< < 1 2 3 4 5 >|