Появилась идея сделать механизм, автоматизирующий вытаскивание полезной информации из html. Скажем, имеем мы в описании справочника очень похожие структуры данных вида



Есть задача вытащить всю полезную информацию, по ходу игнорируя лишние пробелы и переносы. Превратить всё в упорядоченный поток вида

чтобы по нему затем восстановить html. Видно, что  требуются включения рег.выр. и участков кода, зависящие от конкретного списка.  Что-то подобное делается в XSLT, только не кодирование из HTML. Получился бы удобный кодировщик регулярных страниц. Идеально было бы записывать эти преобразования как обратимые.

есть объекты FSO и др. с ними можно генерить новую страницу через JS. 

тебе нужно проходить по дереву, "правильно" собирать innerText каждого тэга.
а свойства тэга можно получить for in.

а в чем, собственно, сложности?

регулярные выражения могут даже не понадобиться.
если хочешь делать без Delphi и др., то простой и удобный вариант на HTA. 
но опять же, ты встретишься с утечкой памяти и косяками JS

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

Вопрос в том, чтобы наглядно описывать выбрасываемые части страницы и сделать достаточно общее решение, чтобы встраивать его.

Кодирующую часть делать всё равно на чём, но лучше на кросссистемных скриптах. JS вполне способен это осилить.

Важно, чтобы потом поменьше программировать. Может, пойти от конца - создания шаблона? Берём образец страницы, заменяем в ней поля переменных на вставки переменных типа <...> или <span class=...>, вставляем учитываем возможность пробелов и переносов где угодно - и вперёд.

хорошо, можно образец сунуть в переменную и использовать в скрипте. понятно.
я думаю, что стоит определиться с форматом шаблона для облегчения поиска с использованием RegExp. 

!TAGNAME! [ 
attr = ... ;
...

]

но тут возникает вопрос: полезная информация - эта та информация, без использования лишних тэгов и атрибутов типа STYLE?

имеет ли смысл придумывать новый формат для последующего создания той же страницы только без мусора?

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

var IMG = [["SRC","значение"],["ALIGN", "top"] ];

очень легко оттуда извлекать информацию и записывать.

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

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

12345c, не понял в чём вопрос...
Собрать документ по шаблону с файла что ты привёл есть дело 10 минут кодинга на PHP. Обраное преобразование (с целого документа в инфу) потребуеться знание шаблона, что тоже просто если перед парсингом шаблон известен. Другой вопрос: а нафига? ты .htm документы справочника в что то другое конвертишь или индексы делаешь?

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

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

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

Вчера, например, по задаче синтеза html придумал такую вещь, как встраивание кода в шаблон, чтобы потом его исполнять в циклах по eval().

Ну было дело, по шаблону генерить страницу: http://forum.vingrad.ru/index.php?showtopic=34621

А вот анализ страницы, это уже другое. Если структуру мы вообще не знаем, то приплываем к классическому вопросу "что было раньше курица или яйцо?"   Анализируя страницу тебе нужна конкретная инфа, а не то что анализатор сумеет "выделить". Например поисковик будет выдлелять крупный текст, в странице, тем самым менюшки и прочее не индексируеться. Крупный текст всегда поделен на блоки (параграфы), в которых присутствует только inline разметка. Если у тебя есть справочник, то ты должен задать его структуру, что бы выделить то, что ты хочешь, иначе задача выруливет в область фантастики с настоящим ИИ, который знает твои увлечения, психотип и т.д. что бы "выделить" нужную инфу 


И что это получилось? Браузер сам может без всяких eval выполнить код в странице, зачем каким то путём доставать верстку со скриптами в переменную, из которой затем вырезать скрипты и выполнять как в шаблонизаторе? В prototype.js есть такая фича, но не врубаюсь где можно это заюзать (мой разум свободен от каких либо паттернов мышления, я сейчас вижу как минимум 2 более красивых решения для подобного функционала, а если задача станет точней, то и решения будут лучше). Не, ну конечно нет предела изврату... 

Резюмирую: какова задача? Я пока вижу три направления:

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

Говори конкретней.

довольно странно... если мы видим банеры, то работаем с IMG или IFRAME. а так вся разборка текста идет по P, DIV, SPAN, ну списки и прочее в том же духе. и то SPAN нужен, в принципе, только для указания стиля. DIV тоже спорный вариант - украшательства через прямоугольники... 
тогда это все наводит на мысль: причем тут "супер разум"?

по-моему цель должна сводится к выделению контента без банеров, где текст классически состоит из P, BR, SPAN, A, списков, элементов управления.. 

по-моему красота проги будет в разграничении HTML, CSS, JSCRIPT..
управление отображением содержимого - через CLASS.

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

говоря о сказанном выше, красота декодирования не нужна особенно в JSCRIPT .. мы сразу сформируем основу. от нее отталкиваемся и меняем стиль содержимого через CSS. даже массив со своей многомерностью не нужен.

если я прав, то деятельность сведется лишь к кодированию на JSCRIPT нового контента без вольностей опять же через FSO и вообще HTA.

Это сообщение отредактировал(а) JSman - 25.8.2006, 00:17

Он может ответить на вопрос: что тебе нужно 
Если мне нужна инфа, то я примерно понимаю как выглядит эта инфа, следовательно пишеться по быстрому анализатор первого типа, либо в редких случаях анализатор второго типа. Повторяю: ты знаешь какую инфу ты хочешь получить и как её достать, ты не отдаёшь "выделение" на откуп софту.


К сожалению не всё в вебе оформлено в виде офисных документов, чаще свёрстано на таблицах с жуткими заморочками. Поисковики ориентируються на количество текста для индексации. Ещё картинки ассоциируються с рядом стоящим текстом, так ты можешь "искать картинки".



Это простой анализатор, в DOM дереве всё раздельно. А вот написать конвертор любой кривой вёрстки в красивую структуру со стилями, да так что визуально во всех браузерах будет одинакого и не отличаться от оригинала... не, памятник при жизни точно народ поставит   Потребуеться рендерить страницу, затем упростить вёрстку применяя фиксированный (в смысле не самообучамый) набор правил по удалению лажи (tidy), после полученное DOM дерево со стилями в файл. Можно даже в XSL-FO, и далее в PDF/DjVu - тогда точно "везде одинакого выглядеть будет". А вот под браузерами с их глюками и особенностями без извратов не возможно.
Нафлеймил   



Подробней на этом моменте, как "сразу сформируем основу"? Возьми страницу yandex.ru к примеру, убедись что там масса мелких картинок, баннерами не являющиеся. Можно посмотреть исходники adblock под лису, они открыты, алгоритм бывает лажает но не часто.

Но! из общего абстрактного анализатора контента предложенного 12345c ты сейчас предлагаешь делать банерорезалку  

итак, я предлагаю сделать на первом этапе "банерорезалку" и то, что разграничит контент в страниц е на JSCRIPT, CSS, HTML. а потом будем бороться с "неправильной" версткой. 

Добавлено @ 02:14 
1й этап - разграничение на 3 логических части.
2й этап - нахождение одинаковых стилей для разных тэгов (например отступы параграфа)
3й этап - поиск альтернативы последовательности тэгов.

Добавлено @ 02:24 
дополнения

между 1м и 2м этапом: "банерорезалка".
по 2му этапу: будем создавать классы и вписывать общие inline-стили. 


а location.href включает .yandex


- это этап №1



на TABLE как я понял, чтобы не спутал с CSS   - этап №3 - борьба с бессмысленной последовательностью

тэгов

Добавлено @ 02:28 
блин, ну если реально сделать эту штуку, то ващще будет

Добавлено @ 02:32 
ребят, я советую сделать на HTML, а не PDF и тд - помучаемся, зато итог классный:

мало весит, код красивый - ай, сказка  

и JSCRIPT впихнем в реализацию кодирования

Сейчас придёт 12345c и будет нас матом крыть за испохабленную идею 

Во вторых, форум != чат, пиши в одном посте 


Вижу ты мало верстал. Можно написать рендер страницы, не графический естественно, мне на первый взгляд на Java уйдёт от силы 2 месяца (для JS можно Rhino прикрутить + стандартные браузерные обьекты). Рендер будет "рисовать" вёрстку в нечто промежуточное со стилями, как это делает браузер. Фактически <p>, <i> и прочие элементы это всё один элемент с разными стилями "по умолчанию".
НО! возникнут проблемы:

• браузеры глючны по определению, вёрстка всё равно будет смотреться криво и по разному в разных бродилках, потому и пользуем извраты.
• 70% JS скриптоделов "знают" JS из пары учебников "за 24 часа", потому скрипты завязанны на конкретной вёрстке, а она то изменяеться.
• проблема филосовского характера - кому это будет нужно? 

В PDF хорошо тем, что рендерит с well-defined XSL-FO, всегда можно тыкнуть пальцем и сказать "ламо написали глюкавый рендер", в отличии от браузеров, которые рождены много раньше чем стандарты которые они должны поддерживать. Конечно результаты представляют чисто научный интерес, ибо в жизни ты с этими PDF'ками... хотя из XSL-FO легко HTML+CSS генерить.


Долго думал... собери мысль по новой 

кстати, он кажется забил уже на нее ))))) не видно его!



нечаянно! просто ночью мысль в голове била!



согласен, но она прикрепляется через атрибуты-события ( ONCLICK="...") - можно присоединить ID и сделать по загрузке attachEvent/addListener либо просто присвоить событию функцию напрямую. проблем нет!

дизайн дизайном, верстка - нечто отдельное. 


ну не скажи.. вот недавно я пришел на фирму, меня попросили переверстать страницы сделанные на frontpage (сколько мусора было! ужас!)! вот эта программа бы понадобилась. а так вручную минут 5 потратил! 12345c тоже хочет.
. 

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


1й этап предлагаю сделать на JSCRIPT ради приличия хоть... товарищи, форум-то джаваскриптовый!

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

Я не про привязку по ID. Например сейчас нет в JS нормального XPath (пинать ленивых разработчиков браузера, и совсем презирать ламов из ECMA, не шевеляться), следовательно приходиться перебирать ноды в ручную. Следовательно ожидаешь что какие то ноды существуют и где они находяться. А тут раз разметка поменялась, скрипты слетели. Зри глубже  


Я бы сказал "обьясни это 80% всех верстальщиков", но не смогу, т.к. сам верстаю с извратами. Почему? Потому что сначала верстаешь хорошо по стандартам, а потом подгоняешь напильником под все браузеры, вот тогда она самая серемяжная правда наружу и вылезает   


Тут сложней анализ будет, front page отстойно вещи на абсолютную позицию ставить любит, следовательно нужно как то проецировать на документ и вгонять в поток документа с нормальными стилями. А это очень даже не простая задача...


А иначе как вынести стили? Выкладывай свою идею 


JSman, давай поменьше бравады и больше здравых мыслей, взрослые же люди всё таки    

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

я ПРЕДЛАГАЮ:
1 этап: разделение на логические части.
полностью убираем из страницы банеры и комментарии (по желанию пользователя).
затем убираем inline-стили, inline-script. в случае стилей - создаем классы, в случае скриптов - привязка по ID. после разделения проверяем страницу на выполнение скриптов. если без ошибок, то все ok. если все-таки скрипт привязали к иерархии, то чуть-чуть сложнее. тогда иерархию не будем трогать. 

итак, первый этап как реализуется.
с помощью JSCRIPT проходим по нодам.
1) убираем атрибуты, имеющие аналогичное значение на CSS, типа как CELLPADDING, CELLSPACING тэга TABLE.
2) создаем классы из инлайн-стилей
3) убираем инлайн-скрипты
4) закрываем незакрытые тэги.
5) приводим тэги согласно XML ( <br /> <img />), разбираемся с перекрываемостью. тем самым, избавляем страницу от ошибок.
6) убираем лишний контент: комментарии, в CSS свойства, начинающиеся на mso-... ( - от MsWord)

что имеем после 1го этапа?
3 строго отдельных части: STYLE, SCRIPT, BODY
иерархия пока не изменена.

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

сложно, очень сложно.. 
тут в первую очередь надо определиться с самой версткой. подумаем над каждым элементом. тело документа будет состоять из 
1) блоков (DIV)  роль блоков - позиционирование (мне кажется только это, если нет поправь меня, + AJAX?)
2) таблицы
3) текстовые элементы: заголовки 6 уровней, параграфы
      в параграфы входят
  а) списки
  б) strong, i (хотя от него отказались W3C) и span (для особых стилей)
  в) анкоры и ссылки
4) инлайн-фреймы.

каждый элемент должен выполнять строго отведенную ему роль.
сначала меняем лишние тэги (например, u на span с классом), неудовлетворяющие нас.
это была подготовка.

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

в случае 2го варианта, нужны заранее созданные стили + избавиться от горизонтальной прокрутки полностью (или учитывать исключения)

1й вариант сложноватый.
что мы имеем.. до фига тэгов с классами. цель - возможное их сокращение и приведение по правилам нашей верстки.
1) надо рассмотреть общее содержимое классов дочерних тэгов одного уровня в иерархии и объединить их. 
2) очень часто при создании в редакторах разработчики по нелепости могут выделить часть текста другим похожим шрифтом на должный. надо убирать лишние шрифты.
3) тоже самое относится к выбору цвета.

пока все было по исправлению верстки.. теперь по теме

3й вариант. добывание полезной информации.. - 
полезность -  понятие относительное!
я думаю , что лучший подход будет таков:
пользователь выделяет мышкой тот контент, который ему нужен. те, прямоугольники, которые не попали, обрабатывать/вносить в заключительную верстку не будем.
если несколько страниц с одного сайта и изначальная верстка хоть как-то соответствует шаблону, то программа может "учиться". по примеру 1-2х страниц, работать над остальной частью.


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

Понадобилось выполнять цикл, включающий фрагмент кода, размещённый в шаблоне. Поэтому вызываю функцию с текстом-кодом. Теперь осталось выявить закономерности в используемых шаблонах, чтобы выработать компактную функцию. Цель в том, чтобы шаблон смотрелся наглядно и естественно, примерно как математический знак суммы.
Конечно, я ориентируюсь на реальные задачи. Сначала задаю структуру, потом запускаю распознаватель. По результатам джб видно, удачна структура или нет. Но в распознаватель надо включить постоянные процедуры типа игнорирования пробелов, чтобы не прописывать каждый раз их явно. Тогда распознавателем будет удобно пользоваться, и, кроме того, он будет показывать ошибки и отклонения от структуры.

Результаты первого действия  выложу в другую тему после того как напишу.

Добавлено @ 12:07 
это первое направление

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

Хотя, есть идея работать по DOM внутри сгенерированной страницы (процедура внедряется через прокси, если это в онлайне вырезают баннеры "на лету" или включается вручную строкой вызова скрипта, если идёт анализ страниц для извлекания информации по шаблону.
JSman, люди уже писали программы выбразывания мусора, сделанного в Frontpage. Если поискать по ресурсам программ, найдётся. Аналогичное должно существовать и для Word.

Но переверстать произвольный текст в правильный - сильно неопределённая задача. Нужно сначала проработат всю технику перевода (что невозможно по объёму исследования поддержки глюков разных версий бр-ров), потом расписывать строение анализатора. Упрощённая версия - ограничиваемся "каноническими" методами, которые тоже надо выделить из опыта правильной вёрстки, которые будут одинаково показываться в бр-рах. Но не исключено, что придёт новая версия и всё испортит.

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

Из режимов я бы добавил к приятному на глаз ещё суперприятный на глаз . Дельное предложение.
Приятность надо сначала вычислить формулой, потом написать операторы  итераций, чтобы потом применить метод Рунге-Кутта .

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

В этом деле появилось ещё 1 направление (тоже опишу в отдельной теме) - вытащить часть вёрстки в JavaScript, чтобы брать её из кешированного скриптового файла. А то, что останется на HTML, должночитаться поисковиками и браузерами с отключённым  JS.
Хороший вариант визуализации выбора контента. Правда, это уже 3-я часть программы, отдельный модуль. Изначально я предполагаю писать шаблон. Потом - подумать, как автоматизировать писание шаблона в визуальной оболочке.

Как? Нука обрисуй алгоритм, по которому можно с большой долей вероятности сказать баннер перед нами или нет. Конечно большинство баннеров имеют фиксированный размер, если работать с DOM деревом, но тогда не известно как он был туда вставлен (какой скрупт). Если парсим текст сами, то как узнать что есть баннер, ведь это почти всегда замороченный JS.



В DOM дереве не существует не закрытых тегов и т.п. дерево уже разобрано, а вот при записи можно конечно привести всё к XHTML. ИМХО задача левая для JS, это не язык, на котором удобно писать анализаторы.




Тебя дизайнеры расстреляют 


Нет, фактически весь документ может быть отображён узлами единого типа, но с разными стилями. div это блочный элемент, т.е. имеет контейнер. Прочти CSS2 спецификацию, многое узнаешь о строении и отрисовке документов.


Как? Эвристика? А может нейронную сеть лет так сотню обучать, тогда может процент ошибок будеть меньше...


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

Добавлено @ 20:15 

Вот это хорошее уточнение, значит ищем по шаблону. Наиболее просто для XML документов, это через XSLT выбрать инфу в точно известных узлах (копировать можно целые поддеревья) в новый документ. Баннеры и прочий меяющийся шум в документе не будет мешать до тех пор, пока XPath выборки указывают на требуемые ноды, т.е. структура документа в целом не меняеться.

Такой шаблон придёться делать для каждой группы документов со своей уникальной структурой. Для юзера удобной шкуркой будет выделение мышью необходимого контента, как уже говорил JSman.

Sardar, документы, из которых придётся что-то извлекать, обычно далеко не xml - справочники, книги, образы сайтов. С дизайном, свёрстанным вручную.

полностью убираем из страницы баннеры [/quote](Если пытаться через JS парсить реальные страницы, прежде прокси-сервером надо удалять содержимое фреймов чужих доменов, иначе не будет работать.)
[quote=Sardar, 26.8.2006,  20:06, post834438]

есть банеры 3х видов: IMG, IFRAME, ActiveXObject (Flash)

IMG делают ссылку на другой хост.
IFRAME - полностью состоит из ссылок и картинок на другой хост (Google)
Flash - вся канва перекрыта объектом button, при клике ведущий, опять же, на другой хост. доступ к объектам через свойства и тд

можно также учитывать их расположение на странице: до/после основного содержимого, отдельно сбоку странички. 

это вообще отдельная тема.



ну ты меня не понял. на этом этапе основной целью является переделка верстки. анализатор по этой части написать можно. даже на регЭксп c js



ты сам знаешь, что красивые и удобные страницы пользователь не захочет править. это лишь дополнительная опция по анализу шрифта и цвета. с mso разговор КААРОТКИЙ. тут понятно.


я замечательно знаю CSS, но, опять же, я же не просто так написал типа по-незнанию.
есть тэги, играющие по нашим правилам.
вот, что я писал

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



по 3му ясно - это выделение мышкой.

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

1е - последовательность тэгов! нужно сводить до минимума положение "контейнер в контейнере" (для див актуально). сложно,конечно, но интересно. и есть другие ситуации.


да. но для боди в некоторых случаях подойдет.

12345c, я прошу тебя четко объяснить, что ты хочешь.
я пока не особо дорубаюсь, чем твоя точка зрения принципиально отличается от изложенного выше. ну торможу я! 

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



Это сообщение отредактировал(а) JSman - 26.8.2006, 23:19

пора определять этапы, товарищи!  

ОК, ладно, чисто ради прикола в свободное время:

• берём любой html парсер, их много
• берём любой CSS парсер, их тоже не мало
• поверх API либ третьих лиц строим свои классы для дерева с одним типом узла, но разными CSS стилями.
• выдаём API для фильтров, что будут перебирать дерево в п.3, модифицироват его. Экспериментируем с идеями.

На всё может уйти месяц. Если запользовать что то подобное http://html.xamjwg.org/cobra.jsp то меньше, но с кодом придёться основательно разобраться. Естественно всё на Java, JS тут физически не возможен 

На досуге покопаюсь в кобре.

для анализа чужих кодов, я же раза 2 об этом написал.

или возможен )))

давайте так (Sardar, 12345c) , пока начнем что-нибудь, потом покажем, совместим, что возможно, подумаем. мне надо хоть в Москву приехать, а то Сочи, море, пляж, отдых в общем. с 5го числа серьезно займусь.

для меня тут и перлом пахнет, дельфи, жс. посмотрим.

JSman, открывай новую тему, выкладывай конкретные маленькие задачи (например парсер CSS в дерево аттрибутов). Дизайн всей этой софтины сам придумай, я лишь с кодом на конкретные задачи в свободное время помогу.