Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
Не совсем понятно, что в итоге делает Ваш парсер.
оффтопик
Если Вам интересно, я делаю поисковую систему по html кодам, имеется база 10+млн страниц. Удобно, что сразу в базе.
оффтопик
Если Вам интересно, я делаю поисковую систему по html кодам, имеется база 10+млн страниц. Удобно, что сразу в базе.
Привет!
Это уже не парсер. А отрисовщик (Render) HTML. То есть, в итоге он будет считать хтмл и отдавать результат расчетов как современные браузеры. Он включает в себя несколько парсеров (HTML, CSS, FONT и ещё будут добавляться) + разные возможности CSS модулей.
Спасибо! Для тестирования я использую commoncrawl.org — там можно получить миллиарды хтмл страниц с разными кодировками и языками.
Это уже не парсер. А отрисовщик (Render) HTML. То есть, в итоге он будет считать хтмл и отдавать результат расчетов как современные браузеры. Он включает в себя несколько парсеров (HTML, CSS, FONT и ещё будут добавляться) + разные возможности CSS модулей.
Спасибо! Для тестирования я использую commoncrawl.org — там можно получить миллиарды хтмл страниц с разными кодировками и языками.
Отличный проект, поддержим автора!
Я так понимаю всё это сулит нам долгожданный браузер, способный держать больше 3х открытых вкладок, не вешая проц и не съжирая 10 гигов оперативки?
Да, именно так, это одна из основных целей.
Хорошо, давайте посмотрим что получится в итоге.
Попробуйте не замахиваться на ВЕСЬ вебкит, в 99% случаев весь мир использует библиотеки вида jquery, достаточно будет добавить в них поддержку именно вашего браузера и большинству этого будет достаточно.
Лучше пусть будет быстро!
p.s. реализуйте в стандарте понятие пакетного менеджера, чтобы была возможность устанавливать общепринятые библиотеки на стороне клиента (и загружать их однократно, даже если они требуются в нескольких вкладках одновременно), т.е. владелец веб-сайта указывает свой репозитарий, с хешами пакетов, и на страницах указывает что то типа
import jquery < 18.2 >= 11.3;
а браузер загружает ее однократно и хранит в кеше, зато если понадобится другому сайту — достаточно будет идентификатора, версии и хеша, чтобы использовать уже загруженную (и проинициализированную)
Лучше пусть будет быстро!
p.s. реализуйте в стандарте понятие пакетного менеджера, чтобы была возможность устанавливать общепринятые библиотеки на стороне клиента (и загружать их однократно, даже если они требуются в нескольких вкладках одновременно), т.е. владелец веб-сайта указывает свой репозитарий, с хешами пакетов, и на страницах указывает что то типа
import jquery < 18.2 >= 11.3;
а браузер загружает ее однократно и хранит в кеше, зато если понадобится другому сайту — достаточно будет идентификатора, версии и хеша, чтобы использовать уже загруженную (и проинициализированную)
Хм, Firefox 24 (ESR) + NoScript, 409 вкладок, 913M/372M (virt/res), загрузка ЦП < 10%, ЧЯДНТ (кроме пользования устаревшей версии браузера)?
Одним из конечных продуктов проекта сделать более быстрый HTML браузер, какие еще есть варианты вашего проекта? Не спроста же ваш работодатель так щедр
В статье я пишу, что браузер это одно из направлений, он как бы логично «вытекает» из этой разработки.
Встраиваемость — это очень важный аспект разработки. Потому и нет зависимостей. Ведь HTML и DOM Events можно использовать не только в браузере. Благодаря тому, что он написан на Си его можно прикрутить к «любому месту». Соответственно получив полнофункциональный рендер хтмл на своем любимо языке программирования. То есть, тут отпадает JavaScript, ведь вы можете напрямую пользоваться АПИ движка. Можно использовать для создания интерфейсов, игр, да чего угодно в своей программе.
Работодатель у меня действительно хороший. Он адекватный и слушает, а главное слышит, то что ему говоришь.
Встраиваемость — это очень важный аспект разработки. Потому и нет зависимостей. Ведь HTML и DOM Events можно использовать не только в браузере. Благодаря тому, что он написан на Си его можно прикрутить к «любому месту». Соответственно получив полнофункциональный рендер хтмл на своем любимо языке программирования. То есть, тут отпадает JavaScript, ведь вы можете напрямую пользоваться АПИ движка. Можно использовать для создания интерфейсов, игр, да чего угодно в своей программе.
Работодатель у меня действительно хороший. Он адекватный и слушает, а главное слышит, то что ему говоришь.
Все же без JS как связующего слоя между HTML5 API (Web Gl, Media Source Extension, Canvas) данный браузер будет «не очень» работать с сайтами которые все же имеют малейшие намеки на динамический контент. Или, к примеру, планируется интерпретатор JS в какой то нативный для платформы скриптовый язык? Что в вашем понимании есть АПИ движка?
Вы немного не поняли. JS будет в браузере, как же без него. Речь о том, что движок можно прикрутить к вашей программе и использовать все его возможности напрямую, минуя JS. Тут речь не о браузере. А именно о том, чтобы использовать возможности HTML/DOM Event/CSS в какой либо программе. То есть, не для рисования страницы хабра, а для создания элементов на хтмл, интерфейсов и прочего.
А почему вы стесняетесь назвать имя то? Он даже на хабре есть https://habrahabr.ru/users/Ashmanov/
Кстати, да, для встраиваемых систем (Техже телевизоров) и «Интернета вещей» — Идеальный вариант.
В своё время так сделали разрабы Opera — движок их браузера был весьма шустрый и досихпор встречается в некоторых телеках и плеерах (У которых начинка «так себе»)
В своё время так сделали разрабы Opera — движок их браузера был весьма шустрый и досихпор встречается в некоторых телеках и плеерах (У которых начинка «так себе»)
Спасибо за наводку!
Есть ещё Duktape, крутая штука для встраивания.
Если Mojo::DOM полностью проходит тесты на построение дерева то можно не беспокоиться о правильности построения дерева.
Насколько помню Mojo написано на Perl без использования библиотек на Си.
Удивительно тут то что HTML::Bare нельзя назвать html парсером, там нет правил построения дерева. Более того не понятно какой элемент чем является.
Вот взять такой хтмл:
Итог должен быть такой:
То есть, тег в конце является текстом, это важно. При этом, парсер HTML::Bare ещё и в два раза отстает от полноценного MyHTML. Вот так и пишут всякое, а называют HTML парсерами, хотя они с ними и рядом не стояли.
Вот взять такой хтмл:
<svg><desc><style><a>
Итог должен быть такой:
<html>
<head>
<body>
<svg:svg>
<desc:svg>
<style>
<-text>: <a>
То есть, тег в конце является текстом, это важно. При этом, парсер HTML::Bare ещё и в два раза отстает от полноценного MyHTML. Вот так и пишут всякое, а называют HTML парсерами, хотя они с ними и рядом не стояли.
Возможно да, но из примера выше ясно, что тот же тег «a» они не верно разберут и соответственно выдадут неверный ответ. Собственно, всё тоже самое можно делать и в myhtml или же использовать селекторы из modest (надо бы их к перлу прикрутить)
cpan: https://metacpan.org/pod/HTML::MyHTML
В хтмл есть условия для каждого тега как и куда ему нужно быть вставленным в хтмл дерево или быть выбращенным при разных условиях. Если вы хотите итог такой же как в любом современном браузере то нужно использовать полноценный парсер, а если вам это не важно то любой простой токенизатор который находит элементы <...>.
В хтмл есть условия для каждого тега как и куда ему нужно быть вставленным в хтмл дерево или быть выбращенным при разных условиях. Если вы хотите итог такой же как в любом современном браузере то нужно использовать полноценный парсер, а если вам это не важно то любой простой токенизатор который находит элементы <...>.
Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.
Т.е. прямо сейчас MyCSS нельзя использовать как замену LibCSS для получения рассчитанных color/background-color произвольной ноды?
Нет, сейчас нельзя. Сейчас, можно получить width, height (CSS). К сожалению я не могу сейчас позволить себе засесть за разработку всех свойств CSS. Хотя и делать там особо нечего. Мною было принято решение делать всё по мере надобности. Или же пока к проекту не подключится кто-то ещё кому можно объяснить как легко можно добавить обработчик того или иного свойства.
Могу вас заверить, что до момента появления поддержки всех CSS свойств осталось не так много времени.
Могу вас заверить, что до момента появления поддержки всех CSS свойств осталось не так много времени.
А возможность добавлять свои свойства и обработчики без правки кода библиотеки — это будет?
В libcss это всё захардкорено внутри неё и нельзя просто так добавить что-то своё.
И это всё будет внутри mycss? Или в вашем проекте это уже часть modest?
В libcss это всё захардкорено внутри неё и нельзя просто так добавить что-то своё.
И это всё будет внутри mycss? Или в вашем проекте это уже часть modest?
Я размышляю об этом, и склоняюсь к мысли сделать для своих свойств какой-то префикс, вроде --mycss-*. Вот тогда можно будет динамически добавлять свои свойства и обработчики к ним. Но, меня остановили рассуждения о том, зачем это может понадобиться? Для чего это потом использовать? Я так и не придумал.
В Modest вшит myhtml и mycss. Но поддерживаются они оба, то есть код mycss идентичен коду его же в modest. В будущем они разойдутся (это надо для движка modest, без этого никак), но совместимость сохранится. Можно будет спокойно использовать код написанный на mycss в modest. Разработка специально идёт так чтобы можно было использовать парсер хтмл и цсс отдельно.
В Modest вшит myhtml и mycss. Но поддерживаются они оба, то есть код mycss идентичен коду его же в modest. В будущем они разойдутся (это надо для движка modest, без этого никак), но совместимость сохранится. Можно будет спокойно использовать код написанный на mycss в modest. Разработка специально идёт так чтобы можно было использовать парсер хтмл и цсс отдельно.
Одного только mycss (без modest) хватит для целей, что бы получить, например, цвет для любой ноды? Как я сейчас использую LibCSS для этого.
Там у него куча сalback'ов для работы с DOM деревом.
Я это имею ввиду.
Там у него куча сalback'ов для работы с DOM деревом.
Я это имею ввиду.
Т.е. получить набор стилей для конкретной ноды с учётом всех приоритетов и инлайновых стилей.
Да, хватит, но тут нужно уточнить, свойства какие уже посчитанные или то, что указал пользователь в css файле?
То есть, font-size можно иметь посчитанный (он наследуется) или же тот что указали в css? В первом варианте это будет всегда число в пикселях (рассчитанное), а во втором то что указал пользователь: 10%, 30em и так далее.
В данный момент я работаю над поддержкой свойств border*, margin*, padding*, font*, display и прочие. Как я уже и говорил, добавляю свойства по мере надобности проекту Modest.
То есть, font-size можно иметь посчитанный (он наследуется) или же тот что указали в css? В первом варианте это будет всегда число в пикселях (рассчитанное), а во втором то что указал пользователь: 10%, 30em и так далее.
В данный момент я работаю над поддержкой свойств border*, margin*, padding*, font*, display и прочие. Как я уже и говорил, добавляю свойства по мере надобности проекту Modest.
На современных HTML страницах много JavaScript, а во все более набирающих популярность SPA их ОЧЕНЬ МНОГО, на порядок больше CSS кода и производительность в таком случае упирается в производительность JS (а точнее, зачастую в скорость манипуляции DOM через JS). Неужели вы планируете поддерживать JavaScript тоже? И даже если так, то затупы JS сведут все оптимизации с парсингом HTML/CSS в никуда.
Привет! JS это отдельная, большая тема для разговора. В предыдущих статьях я писал, что планирую взять сторонний движок, надо понимать, что если я продолжу разработку один то меня просто не хватит на всё, это не реально. Пока я буду разрабатывать одну часть другая просто устареет. В спецификациях всё активно обновляется.
На данный момент я склоняюсь к использованию стороннего JS движка. Но решение я оттягиваю до последнего. Я жду решения людей которые в корне смогут изменить скорость разработки проекта. Соответственно будет и ответ на вопрос как оно там с JS.
Затупы JS — это затупы JS, ничего они не сведут на нет.
На данный момент я склоняюсь к использованию стороннего JS движка. Но решение я оттягиваю до последнего. Я жду решения людей которые в корне смогут изменить скорость разработки проекта. Соответственно будет и ответ на вопрос как оно там с JS.
Затупы JS — это затупы JS, ничего они не сведут на нет.
Дело в том, что SPA приложения практически не загружают HTML c сервера — они его генерируют через JS. Т.е. результирующую страницу вы не получите, пока не отработает весь JS код. В результате получается, что 90 процентов время загрузки страницы тратится на исполнение JS и его взаимодействию с DOM. Создание современного движка JS с поддержкой фич вроде async и генератов видится мне нетривиальной задачей даже для опытной команды. А подключение любого из современных движков JS будет и сложно и неэффективно, т.к. все они (SpiderMonkey, Edge, V8) разработаны с учетом использования из С++ кода и сами на нем же, очевидно, и написаны.
Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servo
Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servo
Речь о том, что JS сам по себе не разбирает CSS или HTML и прочие компоненты, если конечно кто-то не использует разбор CSS/HTML написанный на JS, тут я ничего не сделаю.
А так, да, буквально все кто создает JS движки создают их под себя, тут вы правы.
Мне часто рекомендуют посмотреть на серво, более того даже звали туда работать. Но, к сожалению, или счастью, вынужден отказать.
Я вас услышал, спасибо.
Есть интересная тенденция, каждый раз когда я приступаю к разработке какого либо компонента мне говорят, что ничего не выйдет, ну или я не понимаю куда лезу. Проект открытый, каждый может увидеть что из этого выйдет.
А так, да, буквально все кто создает JS движки создают их под себя, тут вы правы.
Мне часто рекомендуют посмотреть на серво, более того даже звали туда работать. Но, к сожалению, или счастью, вынужден отказать.
Я вас услышал, спасибо.
Есть интересная тенденция, каждый раз когда я приступаю к разработке какого либо компонента мне говорят, что ничего не выйдет, ну или я не понимаю куда лезу. Проект открытый, каждый может увидеть что из этого выйдет.
У проектов предназначение все же разное как я вижу. Этот больше для эмбебеда и скорости парсинга, servo — надежность и использование GPU.
Например собрать servo на десктопе это одно, а под Ubuntu Phone\Sailfish\Pi\Emscripten\Кофеварку — совсем другое.
Про отсутствие JS, автор так же имеет ввиду встраевоемое применение, на например хром через electron встроен в десктопный Slack клиент.
Тут ты сам волен делать все что хочешь и взаимодействие напрямую может быть плюсом.
Например собрать servo на десктопе это одно, а под Ubuntu Phone\Sailfish\Pi\Emscripten\Кофеварку — совсем другое.
Про отсутствие JS, автор так же имеет ввиду встраевоемое применение, на например хром через electron встроен в десктопный Slack клиент.
Тут ты сам волен делать все что хочешь и взаимодействие напрямую может быть плюсом.
Да лучше поучить Rust и присоединиться к проекту Servo https://servo.org/
Из скриптов работа с DOM возможна? Как вы думаете, ваша реализация будет заметно быстрее любой другой из имеющихся в мире (gecko, webkit, presto, edge)?
Задумывались ли вы, какой из стандартов (точнее группы классов функцианальности) вы будете готовы реализовать?
Задумывались ли вы, какой из стандартов (точнее группы классов функцианальности) вы будете готовы реализовать?
Скрипты — это JS? Если да, то нет. JS там пока нет.
Про «лучше всех» я смогу ответить только когда появится первая стабильная версию отрисовщика. Но вообще, конечно, разработка ведется с расчетом на скорость и неприхотливость.
Последний вопрос, к сожаления, не понял. Можете пояснить?
Про «лучше всех» я смогу ответить только когда появится первая стабильная версию отрисовщика. Но вообще, конечно, разработка ведется с расчетом на скорость и неприхотливость.
Последний вопрос, к сожаления, не понял. Можете пояснить?
На совместимость с каким браузером вы хоте ли бы ориентироваться, те же префиксы CSS?
Я ориентируюсь на спецификации, причем на «живые» спецификации. Всё, что связанно с CSS это draft. Всё что связанно с HTML это whatwg.org. Про CSS стоит отметить, что с обязательной оглядкой на «рекомендованные» спецификации.
CSS префиксы в браузерах — это не от хорошей жизни и использовать их не стоит. Создаются они по той причине, что какое-то свойство нужно, а спецификация не определилась ещё как оно должно отрабатывать, или же кто-то из гигантов вводит своё свойство которое потом перетекает в спецификацию.
Отвечая на вопрос прямо, — поддерживать префиксы сторонних браузеров я не буду. По сути, в спецификациях уже всё определенно. Более того современные движки, такие как webkit, уходят от использования префиксов.
Моя цель реализовать качественный движок/браузер опережающий современные в нескольких направлениях: скорость, ресурсы, гибкость (неприхотливость). Впрочем, Modest так и переводится: скромный, неприхотливый.
И конечно же, надо понимать, что проект большой и сложный, и одним человеком такое не пишется. Точнее, пишется, но до определенной стадии. Но и в этом вопросе есть лучи света.
CSS префиксы в браузерах — это не от хорошей жизни и использовать их не стоит. Создаются они по той причине, что какое-то свойство нужно, а спецификация не определилась ещё как оно должно отрабатывать, или же кто-то из гигантов вводит своё свойство которое потом перетекает в спецификацию.
Отвечая на вопрос прямо, — поддерживать префиксы сторонних браузеров я не буду. По сути, в спецификациях уже всё определенно. Более того современные движки, такие как webkit, уходят от использования префиксов.
Моя цель реализовать качественный движок/браузер опережающий современные в нескольких направлениях: скорость, ресурсы, гибкость (неприхотливость). Впрочем, Modest так и переводится: скромный, неприхотливый.
И конечно же, надо понимать, что проект большой и сложный, и одним человеком такое не пишется. Точнее, пишется, но до определенной стадии. Но и в этом вопросе есть лучи света.
Скорее всего автор не очень понимает в чем сложность.
Быстрый парсер это конечно хорошо, но это самая простая часть задачи.
Интересует, как автор планирует отрисовывать хотя бы линию «на любом устройстве где есть Си»?
не говоря уже о взаимодействии с системой: реакция на scroll commands, select, copy и т.д.
Быстрый парсер это конечно хорошо, но это самая простая часть задачи.
Интересует, как автор планирует отрисовывать хотя бы линию «на любом устройстве где есть Си»?
не говоря уже о взаимодействии с системой: реакция на scroll commands, select, copy и т.д.
Не факт что не понимает,
https://github.com/lexborisov/Modest/blob/master/examples/font/glyph_metrics.c
вот этой инфы мне достаточно, чтобы прикрутить к этому nanovg и отрисовать везде, где работает GLES.
https://github.com/lexborisov/Modest/blob/master/examples/font/glyph_metrics.c
вот этой инфы мне достаточно, чтобы прикрутить к этому nanovg и отрисовать везде, где работает GLES.
Тысяча извинений, если я где-то указал, что собираюсь рисовать на любой железке. И если вы на это укажите то я незамедлительно исправлю. А если там нет дисплея? В файл писать? А в какой? PNG, JPG? Или я пишу о расчетах на любой железке? Возможно я и правда ничего не понимаю, столько вопросов.
>открытый движок HTML-рендера на «голом» Си
>Возможность скомпилировать/установить на любом устройстве где есть Си
Может мы по разному понимаем слово «рендерер» или слово «устройство»?
Дело в том что парсер CSS + HTML это ~ 5% задачи, да и то только потому, что HTML не строгий язык, поэтому основная сложность парсинга это парсить багнутые HTMLы также как парсит их Explorer, а он даже нормальные HTMLы парсит багованно и большинство рентереров вынужденны поддерживать эти баги, что бы юзеры не вопили, что Explorer показывает правильно, а ты нет. А объяснять им, что все наоборот, бессмысленно.
В проем если твое слово «рендер» означает только парсинг, то все нормально — пока визуальной части нет, юзеры разницы и не увидят :)
>Возможность скомпилировать/установить на любом устройстве где есть Си
Может мы по разному понимаем слово «рендерер» или слово «устройство»?
Дело в том что парсер CSS + HTML это ~ 5% задачи, да и то только потому, что HTML не строгий язык, поэтому основная сложность парсинга это парсить багнутые HTMLы также как парсит их Explorer, а он даже нормальные HTMLы парсит багованно и большинство рентереров вынужденны поддерживать эти баги, что бы юзеры не вопили, что Explorer показывает правильно, а ты нет. А объяснять им, что все наоборот, бессмысленно.
В проем если твое слово «рендер» означает только парсинг, то все нормально — пока визуальной части нет, юзеры разницы и не увидят :)
Давайте всё же на вы. Рендер — это расчет, расчет всего до состояния «взял и нарисовал» + рисование в файл (по возможности), а вот браузер это уже отрисовка всего на экран со всеми полагающимися плюшками. Вы же понимаете, что рендер создается не зависимо от железки. На «любой железке» свой способ рисовать, вот кто этой самой железкой владеет тот и будет рисовать.
Вы спецификации читали? Почему вы говорите, что основная сложность это парсить битый хтмл? Вы думаете текущий парсер (MyHTML) не умеет верно это парсить? IE тянет только свои древние баги, к которым пользователи привыкли. И думается мне, что они уже 100 раз не рады что когда-то эти баги допустили. Более того, их новый движок, вроде, этих багов уже с собой не тащит. Я не знаю случаев где хром или фф поддерживали бы баги ие, то есть то чего нет в спецификации, а вот из-за прихоти угодить ие.
Я более не буду с вами спорить. Отвечу в вашем же манере, что я считаю грубым, — Скорее всего вы не очень понимаете о чём пишете.
Вы спецификации читали? Почему вы говорите, что основная сложность это парсить битый хтмл? Вы думаете текущий парсер (MyHTML) не умеет верно это парсить? IE тянет только свои древние баги, к которым пользователи привыкли. И думается мне, что они уже 100 раз не рады что когда-то эти баги допустили. Более того, их новый движок, вроде, этих багов уже с собой не тащит. Я не знаю случаев где хром или фф поддерживали бы баги ие, то есть то чего нет в спецификации, а вот из-за прихоти угодить ие.
Я более не буду с вами спорить. Отвечу в вашем же манере, что я считаю грубым, — Скорее всего вы не очень понимаете о чём пишете.
Вот — как я и предполагал проблема в слове «рендерер HTML» для меня это отрисовка и UI. А для вас это расчет параметров из HTML + CSS.
Не путайте людей, то что вы пишите это не редерер, это DOM — дерево объектов, возможно с ссылками на подходящие CSS стили.
А сам по себе DOM вряд ли кому-то нужен.
Не путайте людей, то что вы пишите это не редерер, это DOM — дерево объектов, возможно с ссылками на подходящие CSS стили.
А сам по себе DOM вряд ли кому-то нужен.
Простите, но путаете людей тут только вы. DOM — это DOM. Я говорю, более того я делаю, рендер HTML, если слова Render Tree/Layers вам что-то говорят то вы должны понимать. Я делаю довольно сложную «штуку», а DOM это малая часть этой «штуки».
Что-то вы меня запутали. Если рендер это отрисовка, а Tree/Layers это дерево/слои. То какое дерево и какие слои вы отрисовываете? и куда?
«RenderHtml» это разве не отрисовка боксов, бордюров, текста, имеджей и т.д.? Что должен делать ваш рендер HTML?
«RenderHtml» это разве не отрисовка боксов, бордюров, текста, имеджей и т.д.? Что должен делать ваш рендер HTML?
А вы не путайтесь. Render и show или display — разные слова. Это расчет модели (положения элементов, их цвета и т.д.), а где она будет отображаться и как, другой вопрос.
Ре́ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения
В прочем я уже понял, что данный проект имеет весьма косвенное отношение к HTML Browser, но остальные поняли автора именно так — парень делает с нуля HTML viewer!
Хотя по его же словам от делает «довольно сложную «штуку»». (забавные слова для программиста)
А зачем эта «сложная штука» нужна и что она будет делать в итоге, он так и не сказал.
В прочем я уже понял, что данный проект имеет весьма косвенное отношение к HTML Browser, но остальные поняли автора именно так — парень делает с нуля HTML viewer!
Хотя по его же словам от делает «довольно сложную «штуку»». (забавные слова для программиста)
А зачем эта «сложная штука» нужна и что она будет делать в итоге, он так и не сказал.
Ну все верно, получение изображения, а не отображение его на конкретном устройстве. Парень все сказал, есть разные области отвественности, кто-то рендерит, а кто-то выводит на конкретный экран или в файл, например.
И для чего нужно, сто раз уже написано, для поддержки быстрого HTML на всех на свете устройствах, от часов до стиральных машин.
И для чего нужно, сто раз уже написано, для поддержки быстрого HTML на всех на свете устройствах, от часов до стиральных машин.
Интересный проект. Реально ли сделать аналог PhantomJS, но для вашего движка?
Спасибо! Да, конечно, но лишь когда будет реализован JS и ещё не мало чего. В PhantomJS всегда раздражал тот факт, что нужно дождаться окончания полной загрузки страницы (выполнение всех скриптов и прочего). То есть, он может позволить себе висеть до 10-20 секунд прежде чем ему можно будет что-то отработать. Возможно там уже что-то поменялось, но раньше это был webkit с которым ты общаешься через JS. Я же хочу предоставить пользователю полный контроль, начиная от HTML дерева заканчивая Redner Tree с простым и понятным API.
Блин, было бы супер, если бы его можно было приспособить для browser-less консольной прогонки тестов UI. Сейчас это phantomjs — но он ужасно медленный.
на это смотрели? Весьма достойный конкурент.
Привет, только вот вчера смотрел. Сложно с кем-то мёртвым конкурировать «HTMLayout is not supported anymore, please use Sciter instead. Sciter is a superset of HTMLayout and works on Windows, Mac OS X and Linux». Да и сравнения там с FF 1.0 и IE 6.0, крайне странно. Так же не понятно насколько покрывает спецификацию эта штука и какой версии.
Могу только пожелать удачи!
Очень впечатляет! Мне кажется мало кто понимает то, насколько этот проект в случае успеха изменит мир.
Ничего он не изменит. Автор получит через 2-3 года клон IE 1.0, и всё. У тебя «нефтяной» максимализм, типа вот щас-щас вотчучуть и заживем, пендосы саснут, ря! Лучшебы автор V8 в 10 раз ускорил или еще чего. Или рендер у хрома, раз он его пишет.
Не люблю отвечать на подобные комментарии, но исключение надо делать иногда.
Вы видимо знающий человек в этой области. Ведь вы утверждаете, что полтора человека это могут сделать (где-то выше утверждали), то вот чётко уверены, что через два-три года будет клон IE 1.0. Вы и исходники все посмотрели, и спецификации все почитали, и знаете как всё устроено?
Вообще, как можно писать, что я получу IE 1.0 через два года когда уже все новое написано и разрабатывается по последним спецификациям. Я даже слов подобрать не могу, это какой-то абсурд. Вы тролль?
Зачем мне идти и помогать гуглу, фаерфоксу? Там работают люди, программисты и прочие, которые получают за свою работу деньги, как и я собственно, а тут я должен всё бросить, и помогать какой-то зарубежной компании — зачем? Тем более в том продукте стратегию разработки которого я не разделяю с ними. Вы вот чем занимаетесь? Почему вы не помогаете гуглу? Вы видимо большой специалист в этой сфере, помогите гуглу, а то вдруг не успеете и он закроет проект.
Вы видимо знающий человек в этой области. Ведь вы утверждаете, что полтора человека это могут сделать (где-то выше утверждали), то вот чётко уверены, что через два-три года будет клон IE 1.0. Вы и исходники все посмотрели, и спецификации все почитали, и знаете как всё устроено?
Вообще, как можно писать, что я получу IE 1.0 через два года когда уже все новое написано и разрабатывается по последним спецификациям. Я даже слов подобрать не могу, это какой-то абсурд. Вы тролль?
Зачем мне идти и помогать гуглу, фаерфоксу? Там работают люди, программисты и прочие, которые получают за свою работу деньги, как и я собственно, а тут я должен всё бросить, и помогать какой-то зарубежной компании — зачем? Тем более в том продукте стратегию разработки которого я не разделяю с ними. Вы вот чем занимаетесь? Почему вы не помогаете гуглу? Вы видимо большой специалист в этой сфере, помогите гуглу, а то вдруг не успеете и он закроет проект.
День добрый.
Не подскажете, на чем GUI пишется? Будет ли порт под мобильные платформы?
Спасибо.
Не подскажете, на чем GUI пишется? Будет ли порт под мобильные платформы?
Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Modest — разработка открытого движка HTML рендера на «голом» Си