Всем привет! Меня зовут Александр Борисов и я разрабатываю Modest — открытый движок HTML-рендера на «голом» Си без использования внешних зависимостей (далее движок). Сразу хочется пояснить, что значит «без внешних зависимостей» — весь код пишется с нуля, код нигде не заимствован.

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

О Проекте


Основная идея проекта заключается в его неприхотливости, а это значит:

— Возможность скомпилировать/установить на любом устройстве где есть Си
— Скорость работы
— Минимально возможное потребление ресурсов

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

Обо всём по порядку


Возможность скомпилировать/установить на любом устройстве где есть Си

Идея заключается не только в том, чтобы иметь возможность скомпилировать/установить на любой железке, ведь Си есть практически везде, но и иметь возможность подключить движок к другому языку программирования раскрывая для этого языка полный спектр API движка. Говоря проще, иметь возможность легко сделать binding (обвязку) для вашего языка программирования.

Что же нам дадут обвязки на других языках?

Простое и понятное API движка даст нам возможность напрямую работать с HTML Tree, CSS, Render Tree/Layers (Дерево отрисовки/слои) через наш любимый язык программирования, без использования JavaScript.

На практике это будет означать следующее:

  1. Высокая скорость доступа, создания, изменения элементов/слоёв.
  2. Лёгкость создания интерфейсов, игр, приложений через знакомый вам язык программирования с использованием всех возможностей HTML/DOM Events/CSS.

Более того, я пошёл дальше и протестировал следующее
Сразу оговорюсь, что это лишь эксперимент, зачем оно в жизни так может понадобиться не ясно, но сделать можно.

  1. Берём готовую обвязку для Perl и меняем её
  2. Добавляем в обработку тега script тип Perl: <script type="Per">
  3. Разбираем хтмл в Perl
  4. Когда парсер встречает тег script с типом Perl то он выполняет этот код в текущем интерпретаторе


Скрипт на Perl получился такой:
use utf8;
use strict;
use warnings;

use HTML::MyHTML::Fun;

my $html = q~
<div>
	<span>text</span>
</div>

<script type="Perl">
    # $MyHTML_TREE global var
	my $nodes = $MyHTML_TREE->get_elements_by_tag_name("span");
	
	foreach my $node (@$nodes) {
		$node->delete($MyHTML_TREE);
	}
</script>

<span>footer</span>
~;

# parse HTML
my $myhtml = HTML::MyHTML->new(MyHTML_OPTIONS_DEFAULT, 1);
my $tree = $myhtml->new_tree();

$myhtml->parse($tree, MyHTML_ENCODING_UTF_8, $html);


Результат обработки:

<html>
	<head>
	<body>
		<div>
		<script type="Perl">
            <-text>: ...
		<span>
			<-text>: footer


Скорость работы

Ждать никто не любит, а я особенно. Один из ключевых моментов разработки — это обеспечение быстрой обработки той или иной части HTML/CSS/Render. К примеру, среднее время обработки типичной хтмл страницы равна 0.001 сек., то есть 1мс, а это 1000 страниц в секунду. Разбор CSS файла bootstrap и его селекторов обходится в 1.5мс. На данный момент мы имеем самый быстрый полноценный парсер HTML и CSS. И это не предел.

Минимально возможное потребление ресурсов

Если, со скоростью работы всё более или менее понятно, то вот с потреблением ресурсов всё значительно сложнее. Спецификации обычно «советую/требуют» всё хранить в памяти. Точнее не так, все рассуждения идут так, словно у нас уже всё под рукой, всё создано.

В чём же это проявляется?

Возьмём, к примеру, спецификацию CSS синтаксиса. Она нам говорит, что мы должны создать токены на каждый символ/последовательность символов и разложить их по группам, создать группы токенов. Говоря прямо, — мы должны создавать токены на каждый символ не входящий в общие правила токенизации (delim-token), а так же на каждые: ";", ":", "(", ")", "," и прочие, полный список правил можно увидеть тут.

Согласитесь, что создавать токен на каждую запятую или точку с запятой довольно расточительное занятие. При этом, стоит отметить, что в правилах токенизации символов присутствуют условия вроде таких: имея текущий символ посмотрите, что следующие Н равны Х, иначе создайте Y.

Позже, когда все токены будут созданы их нужно разобрать. То есть, из последовательности созданных токенов выделить группы. И именно эти группы используют модули CSS, которых не мало.

Вот тут и начинается интересное. Мы должны полностью соответствовать спецификации, но сделать так чтобы не создавать токены на каждый чих. Не мало читая спецификации и раздумывая о том, как не создавать «лишних» токенов и экономить память, сформировались следующие условия:

1) Разбор CSS должен поддерживать куски (chunks), то есть разбор потока (stream parsing). Этого спецификация не требует, но это важно для дальнейшего развития. 

Именно из-за этого условия мы не знаем когда закончится поток данных, для нас он бесконечный. То есть, в любой момент времени мы гарантированно имеем только текущий и все предыдущие символы, но понятия не имеем что дальше, и соответственно не можем посмотреть по условию «если пришел символ А то смотрим есть ли дальше открывающая скобка».

2) Не создаем все токены, создаём только один, который в дальнейшем будет постоянно перезаписываться. В любой момент времени, мы имеем только один токен, текущий токен. Соответственно, мы не можем посмотреть предыдущий или следующий токен, их нет. По началу это казалось проблемой, так как в спецификации не мало условий вроде «если пришел токен Х, то смотрите следующие три токена, и если они не H то тогда Y».

Всё выше описанное реализовано в MyCSS. Уже сейчас MyCSS успешно разбирает селекторы и некоторые CSS свойства потребляя минимальное количество памяти. Соответственно, если мы постоянно не ходим за «кусочками» памяти, то и скорость у нас возрастает значительно.

И в довесок ко всему выше сказанному, парсер MyCSS сохранил понятность, гибкость, лёгкость в дальнейшей разработке модулей к нему.

К слову, в MyHTML всё реализовано ровно наоборот. Там упор на создание токенов и дальнейшую работу с ними. Это наглядно показывает, что в таком деле как написание отрисовщика HTML нельзя использовать «серебряную пулю». Везде нужен индивидуальный подход. Ну, и конечно же, всё это нельзя создать без полного понимания спецификаций и того, что в спецификации требуют.

Текущая структура проекта


На данный момент реализованны следующие части проекта:

  1. MyHTML — парсер HTML
  2. MyCSS — парсер CSS (Selectors, Values, Namespace, Property)
  3. MyFONT — парсер .otf и .fft файлов. Получение метрик для глифов: width, height, baseline, x-height и прочие. Стоит отметить, что тут речь идёт о размерах символов, как в браузерах. Смотрите пример.

О селекторах


Писать отдельную статью о селекторах я не вижу смысла, а похвастаться хочется. Уже сейчас можно использовать селекторы для нахождения нод в дереве:

div > :nth-child(2n+1):not(:has(a))

или списком церез запятую

.header, :nth-child(2n+2 of div:not([id])) >> :not(:has(> [class ~= "bukabyaka" i]))

Работают они довольно шустро. Выше, первый, приведенный селектор на типичной статье хабра отрабатывает за 0.00015 сек., то есть за 0.15мс, и находит 247 элементов. В это время входит разбор CSS, разбор и создание селекторов, поиск по дереву. Можно создать селектор заранее и использовать многократно, что позволит уменьшить время работы.

На данный момент, поддерживаются все селекторы из спецификации четверной версии (Selectors 4) за исключением:

  1. Всех псевдо-элементов (pseudo-elements)
  2. :dir, :lang, :scope, «Time-dimensional Pseudo-classes», :drop
  3. :nth-column, :nth-last-column

Первые и вторые будут разрабатываться/добавляться по мере разработки движка. До третьих руки не дошли, но, конечно же, они так же будут реализованы в ближайшем будущем.

Будущее проекта


Оно (будущее) видится очень светлым. Проектом занимаюсь в рабочее время. Мой работодатель разрешил мне тратить всё рабочее время на проект, конечно, если что-то просят сделать приходится отвлекаться.

Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.

Идей очень много, а «бензина» во мне ещё больше! Спасибо за внимание!

P.S.: Если у кого-нибудь возникнет желание помочь/поучаствовать в реализации проекта то можно смело писать на почту.

Ссылки:

» Modest
» Примеры Modest
» Примеры MyHTML
» Примеры MyCSS
» Обвязка MyHTML для Perl
Поделиться с друзьями
-->

Комментарии (81)


  1. azsx
    12.09.2016 13:00
    +1

    Не совсем понятно, что в итоге делает Ваш парсер.
    оффтопик
    Если Вам интересно, я делаю поисковую систему по html кодам, имеется база 10+млн страниц. Удобно, что сразу в базе.


    1. lastmac
      12.09.2016 13:07

      Привет!

      Это уже не парсер. А отрисовщик (Render) HTML. То есть, в итоге он будет считать хтмл и отдавать результат расчетов как современные браузеры. Он включает в себя несколько парсеров (HTML, CSS, FONT и ещё будут добавляться) + разные возможности CSS модулей.

      Спасибо! Для тестирования я использую commoncrawl.org — там можно получить миллиарды хтмл страниц с разными кодировками и языками.


  1. dmx102
    12.09.2016 13:12
    +3

    Отличный проект, поддержим автора!


    1. lastmac
      12.09.2016 13:17

      Спасибо!


  1. Fox_exe
    12.09.2016 13:15
    +3

    Я так понимаю всё это сулит нам долгожданный браузер, способный держать больше 3х открытых вкладок, не вешая проц и не съжирая 10 гигов оперативки?


    1. lastmac
      12.09.2016 13:17
      +5

      Да, именно так, это одна из основных целей.


      1. numitus2
        12.09.2016 13:53
        +10

        К сожалению когда вы полностью реализуете совместимость с web-kit вы поймете, что вся память уходит на dom, и на скрипты.


        1. lastmac
          12.09.2016 13:54
          +5

          Хорошо, давайте посмотрим что получится в итоге.


          1. rPman
            12.09.2016 15:35
            -7

            Попробуйте не замахиваться на ВЕСЬ вебкит, в 99% случаев весь мир использует библиотеки вида jquery, достаточно будет добавить в них поддержку именно вашего браузера и большинству этого будет достаточно.

            Лучше пусть будет быстро!

            p.s. реализуйте в стандарте понятие пакетного менеджера, чтобы была возможность устанавливать общепринятые библиотеки на стороне клиента (и загружать их однократно, даже если они требуются в нескольких вкладках одновременно), т.е. владелец веб-сайта указывает свой репозитарий, с хешами пакетов, и на страницах указывает что то типа
            import jquery < 18.2 >= 11.3;
            а браузер загружает ее однократно и хранит в кеше, зато если понадобится другому сайту — достаточно будет идентификатора, версии и хеша, чтобы использовать уже загруженную (и проинициализированную)


    1. danfe
      13.09.2016 05:21
      -2

      Хм, Firefox 24 (ESR) + NoScript, 409 вкладок, 913M/372M (virt/res), загрузка ЦП < 10%, ЧЯДНТ (кроме пользования устаревшей версии браузера)?


      1. ainu
        13.09.2016 11:54
        +7

        NoScript


  1. HajaPura
    12.09.2016 13:23

    Одним из конечных продуктов проекта сделать более быстрый HTML браузер, какие еще есть варианты вашего проекта? Не спроста же ваш работодатель так щедр


    1. lastmac
      12.09.2016 13:31
      +1

      В статье я пишу, что браузер это одно из направлений, он как бы логично «вытекает» из этой разработки.
      Встраиваемость — это очень важный аспект разработки. Потому и нет зависимостей. Ведь HTML и DOM Events можно использовать не только в браузере. Благодаря тому, что он написан на Си его можно прикрутить к «любому месту». Соответственно получив полнофункциональный рендер хтмл на своем любимо языке программирования. То есть, тут отпадает JavaScript, ведь вы можете напрямую пользоваться АПИ движка. Можно использовать для создания интерфейсов, игр, да чего угодно в своей программе.

      Работодатель у меня действительно хороший. Он адекватный и слушает, а главное слышит, то что ему говоришь.


      1. HajaPura
        12.09.2016 13:37

        Все же без JS как связующего слоя между HTML5 API (Web Gl, Media Source Extension, Canvas) данный браузер будет «не очень» работать с сайтами которые все же имеют малейшие намеки на динамический контент. Или, к примеру, планируется интерпретатор JS в какой то нативный для платформы скриптовый язык? Что в вашем понимании есть АПИ движка?


        1. lastmac
          12.09.2016 14:01
          +2

          Вы немного не поняли. JS будет в браузере, как же без него. Речь о том, что движок можно прикрутить к вашей программе и использовать все его возможности напрямую, минуя JS. Тут речь не о браузере. А именно о том, чтобы использовать возможности HTML/DOM Event/CSS в какой либо программе. То есть, не для рисования страницы хабра, а для создания элементов на хтмл, интерфейсов и прочего.


      1. mr_tron
        12.09.2016 15:45
        +1

        А почему вы стесняетесь назвать имя то? Он даже на хабре есть https://habrahabr.ru/users/Ashmanov/


        1. lastmac
          12.09.2016 15:48
          +1

          Имени у меня не спрашивали, но и секрета тут нет. Работаю я в Крибрум, сижу на одном этаже между Инфовотч и Ашманов и Партнеры. Из чего так же можно сделать вывод, что главные у нас Игорь Ашманов и Наталья Касперская.


      1. Fox_exe
        12.09.2016 22:04

        Кстати, да, для встраиваемых систем (Техже телевизоров) и «Интернета вещей» — Идеальный вариант.
        В своё время так сделали разрабы Opera — движок их браузера был весьма шустрый и досихпор встречается в некоторых телеках и плеерах (У которых начинка «так себе»)


        1. webschik
          13.09.2016 09:40
          +1

          Вместе с JerryScript :)


          1. lastmac
            13.09.2016 12:08

            Спасибо за наводку!


          1. Azq2
            13.09.2016 13:25

            Есть ещё Duktape, крутая штука для встраивания.


  1. kloppspb
    12.09.2016 13:37

    Интересно. По скорости HTML::MyHTML уделывает Mojo::DOM почти в 40 раз. Вот сравнить бы ещё на корректность построения дерева…


    1. lastmac
      12.09.2016 13:41

      Если Mojo::DOM полностью проходит тесты на построение дерева то можно не беспокоиться о правильности построения дерева.


    1. RPG18
      12.09.2016 14:21

      Насколько помню Mojo написано на Perl без использования библиотек на Си.


      1. kloppspb
        13.09.2016 03:18

        Да, по-хорошему надо сравнивать с кем-то, у кого парсер тоже сишный. Самый быстрый из перловых модулей, наверное, HTML::Bare, с сишным ядром. Но и он проигрывает HTML::MyHTML. Правда, не в 40 раз, а всего в два, но тоже неплохо :)


        1. lastmac
          13.09.2016 10:46

          Удивительно тут то что HTML::Bare нельзя назвать html парсером, там нет правил построения дерева. Более того не понятно какой элемент чем является.

          Вот взять такой хтмл:

          <svg><desc><style><a>
          

          Итог должен быть такой:
          <html>
          	<head>
          	<body>
          		<svg:svg>
          			<desc:svg>
          				<style>
          					<-text>: <a>
          


          То есть, тег в конце является текстом, это важно. При этом, парсер HTML::Bare ещё и в два раза отстает от полноценного MyHTML. Вот так и пишут всякое, а называют HTML парсерами, хотя они с ними и рядом не стояли.


          1. kloppspb
            14.09.2016 13:41

            У них совсем другие задачи. 80% из них выглядят как-то так: «а дай-ка мне значение href у a, который находится внутри дива с классом foo» или «найди все p у который есть атрибут bar с любым значением». Ещё 20% — другая мелочёвка, с которой они тоже вполне справляются.


            1. lastmac
              14.09.2016 14:10

              Возможно да, но из примера выше ясно, что тот же тег «a» они не верно разберут и соответственно выдадут неверный ответ. Собственно, всё тоже самое можно делать и в myhtml или же использовать селекторы из modest (надо бы их к перлу прикрутить)


              1. kloppspb
                14.09.2016 14:27

                >всё тоже самое можно делать и в myhtml

                Вот как раз и смотрю :) Но что сразу в минус (это к качеству работы уже отношения не имеет): нет в CPAN. Да и название такое там могут завернуть…

                Что касается разбора, то я плотно работал только с HTML::Tree и Mojo::DOM.

                Первый вообще пример разбирает так:
                html(tag)->{ [head(tag)->style(tag)], [body(tag)->a(tag)] }.

                Второй так:
                svg(tag)->desc(tag)->style(tag)->a(tag)

                Но это никак до сих не мешает решать задачи типа тех, про которые писал. Чуть посложней, конечно, но что-то вроде. Объёмы перелопачиваемых данных — до 10 тысяч разных страниц в сутки, на явные некорректности не нарывался. Может и повезло, конечно :)


                1. lastmac
                  14.09.2016 14:49

                  cpan: https://metacpan.org/pod/HTML::MyHTML

                  В хтмл есть условия для каждого тега как и куда ему нужно быть вставленным в хтмл дерево или быть выбращенным при разных условиях. Если вы хотите итог такой же как в любом современном браузере то нужно использовать полноценный парсер, а если вам это не важно то любой простой токенизатор который находит элементы <...>.


                  1. kloppspb
                    14.09.2016 15:02

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

                    Как в браузере не надо. Но токенизатора не хватит, кроме поиска и манипуляции с деревом нужны. И вставка, и удаление, и замена атрибутов. Но в любом случае скорость MyHTML — это киллер фича даже в этом случае :)


                    1. lastmac
                      15.09.2016 17:37

                      В сишной версии есть всё связанное с работой с деревом: добавление, удаление, изменение. Катастрофически не хватает времени доделать обвязку для перла.


  1. Azq2
    12.09.2016 13:39

    Сейчас, я приступил к созданию дерева отрисовки (Render Tree, Layers). То есть, уже в недалёком будущем можно будет получать рассчитанные метрики хтмл нод, такие как width, height, font-size, border-color и прочие.


    Т.е. прямо сейчас MyCSS нельзя использовать как замену LibCSS для получения рассчитанных color/background-color произвольной ноды?


    1. lastmac
      12.09.2016 13:47

      Нет, сейчас нельзя. Сейчас, можно получить width, height (CSS). К сожалению я не могу сейчас позволить себе засесть за разработку всех свойств CSS. Хотя и делать там особо нечего. Мною было принято решение делать всё по мере надобности. Или же пока к проекту не подключится кто-то ещё кому можно объяснить как легко можно добавить обработчик того или иного свойства.

      Могу вас заверить, что до момента появления поддержки всех CSS свойств осталось не так много времени.


      1. Azq2
        14.09.2016 14:57

        А возможность добавлять свои свойства и обработчики без правки кода библиотеки — это будет?
        В libcss это всё захардкорено внутри неё и нельзя просто так добавить что-то своё.

        И это всё будет внутри mycss? Или в вашем проекте это уже часть modest?


        1. lastmac
          14.09.2016 15:28

          Я размышляю об этом, и склоняюсь к мысли сделать для своих свойств какой-то префикс, вроде --mycss-*. Вот тогда можно будет динамически добавлять свои свойства и обработчики к ним. Но, меня остановили рассуждения о том, зачем это может понадобиться? Для чего это потом использовать? Я так и не придумал.

          В Modest вшит myhtml и mycss. Но поддерживаются они оба, то есть код mycss идентичен коду его же в modest. В будущем они разойдутся (это надо для движка modest, без этого никак), но совместимость сохранится. Можно будет спокойно использовать код написанный на mycss в modest. Разработка специально идёт так чтобы можно было использовать парсер хтмл и цсс отдельно.


          1. Azq2
            14.09.2016 15:43

            Одного только mycss (без modest) хватит для целей, что бы получить, например, цвет для любой ноды? Как я сейчас использую LibCSS для этого.
            Там у него куча сalback'ов для работы с DOM деревом.
            Я это имею ввиду.


            1. Azq2
              14.09.2016 15:51

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


              1. lastmac
                14.09.2016 15:56

                Да, всё это можно будет получить для конкретной ноды. Но всё это уже не mycss, а modest. Именно над этим и работаю. Создаю Render Tree.


            1. lastmac
              14.09.2016 15:54

              Да, хватит, но тут нужно уточнить, свойства какие уже посчитанные или то, что указал пользователь в css файле?
              То есть, font-size можно иметь посчитанный (он наследуется) или же тот что указали в css? В первом варианте это будет всегда число в пикселях (рассчитанное), а во втором то что указал пользователь: 10%, 30em и так далее.

              В данный момент я работаю над поддержкой свойств border*, margin*, padding*, font*, display и прочие. Как я уже и говорил, добавляю свойства по мере надобности проекту Modest.


  1. x512
    12.09.2016 14:00
    +1

    На современных HTML страницах много JavaScript, а во все более набирающих популярность SPA их ОЧЕНЬ МНОГО, на порядок больше CSS кода и производительность в таком случае упирается в производительность JS (а точнее, зачастую в скорость манипуляции DOM через JS). Неужели вы планируете поддерживать JavaScript тоже? И даже если так, то затупы JS сведут все оптимизации с парсингом HTML/CSS в никуда.


    1. lastmac
      12.09.2016 14:14
      +2

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

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

      Затупы JS — это затупы JS, ничего они не сведут на нет.


      1. x512
        12.09.2016 15:12
        +9

        Дело в том, что SPA приложения практически не загружают HTML c сервера — они его генерируют через JS. Т.е. результирующую страницу вы не получите, пока не отработает весь JS код. В результате получается, что 90 процентов время загрузки страницы тратится на исполнение JS и его взаимодействию с DOM. Создание современного движка JS с поддержкой фич вроде async и генератов видится мне нетривиальной задачей даже для опытной команды. А подключение любого из современных движков JS будет и сложно и неэффективно, т.к. все они (SpiderMonkey, Edge, V8) разработаны с учетом использования из С++ кода и сами на нем же, очевидно, и написаны.

        Так что я искренне вам рекомендую посмотреть на https://github.com/servo/servo


        1. lastmac
          12.09.2016 15:43
          +3

          Речь о том, что JS сам по себе не разбирает CSS или HTML и прочие компоненты, если конечно кто-то не использует разбор CSS/HTML написанный на JS, тут я ничего не сделаю.
          А так, да, буквально все кто создает JS движки создают их под себя, тут вы правы.

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

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


        1. lieff
          12.09.2016 15:44

          У проектов предназначение все же разное как я вижу. Этот больше для эмбебеда и скорости парсинга, servo — надежность и использование GPU.
          Например собрать servo на десктопе это одно, а под Ubuntu Phone\Sailfish\Pi\Emscripten\Кофеварку — совсем другое.
          Про отсутствие JS, автор так же имеет ввиду встраевоемое применение, на например хром через electron встроен в десктопный Slack клиент.
          Тут ты сам волен делать все что хочешь и взаимодействие напрямую может быть плюсом.


  1. Beholder
    12.09.2016 14:47
    +1

    Да лучше поучить Rust и присоединиться к проекту Servo https://servo.org/


  1. rPman
    12.09.2016 15:29

    Из скриптов работа с DOM возможна? Как вы думаете, ваша реализация будет заметно быстрее любой другой из имеющихся в мире (gecko, webkit, presto, edge)?
    Задумывались ли вы, какой из стандартов (точнее группы классов функцианальности) вы будете готовы реализовать?


    1. lastmac
      12.09.2016 16:02

      Скрипты — это JS? Если да, то нет. JS там пока нет.
      Про «лучше всех» я смогу ответить только когда появится первая стабильная версию отрисовщика. Но вообще, конечно, разработка ведется с расчетом на скорость и неприхотливость.
      Последний вопрос, к сожаления, не понял. Можете пояснить?


      1. rPman
        13.09.2016 23:56

        На совместимость с каким браузером вы хоте ли бы ориентироваться, те же префиксы CSS?


        1. lastmac
          14.09.2016 10:02

          Я ориентируюсь на спецификации, причем на «живые» спецификации. Всё, что связанно с CSS это draft. Всё что связанно с HTML это whatwg.org. Про CSS стоит отметить, что с обязательной оглядкой на «рекомендованные» спецификации.

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

          Отвечая на вопрос прямо, — поддерживать префиксы сторонних браузеров я не буду. По сути, в спецификациях уже всё определенно. Более того современные движки, такие как webkit, уходят от использования префиксов.

          Моя цель реализовать качественный движок/браузер опережающий современные в нескольких направлениях: скорость, ресурсы, гибкость (неприхотливость). Впрочем, Modest так и переводится: скромный, неприхотливый.

          И конечно же, надо понимать, что проект большой и сложный, и одним человеком такое не пишется. Точнее, пишется, но до определенной стадии. Но и в этом вопросе есть лучи света.


  1. Durimar123
    12.09.2016 18:52
    -1

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

    не говоря уже о взаимодействии с системой: реакция на scroll commands, select, copy и т.д.


    1. lieff
      12.09.2016 19:17
      +2

      Не факт что не понимает,
      https://github.com/lexborisov/Modest/blob/master/examples/font/glyph_metrics.c
      вот этой инфы мне достаточно, чтобы прикрутить к этому nanovg и отрисовать везде, где работает GLES.


      1. lookid
        12.09.2016 23:54
        -10

        Тебе этого достаточно чтобы на хабре об этом комментарий написать.


    1. lastmac
      13.09.2016 00:30
      +3

      Тысяча извинений, если я где-то указал, что собираюсь рисовать на любой железке. И если вы на это укажите то я незамедлительно исправлю. А если там нет дисплея? В файл писать? А в какой? PNG, JPG? Или я пишу о расчетах на любой железке? Возможно я и правда ничего не понимаю, столько вопросов.


      1. Durimar123
        13.09.2016 10:38

        >открытый движок HTML-рендера на «голом» Си
        >Возможность скомпилировать/установить на любом устройстве где есть Си

        Может мы по разному понимаем слово «рендерер» или слово «устройство»?

        Дело в том что парсер CSS + HTML это ~ 5% задачи, да и то только потому, что HTML не строгий язык, поэтому основная сложность парсинга это парсить багнутые HTMLы также как парсит их Explorer, а он даже нормальные HTMLы парсит багованно и большинство рентереров вынужденны поддерживать эти баги, что бы юзеры не вопили, что Explorer показывает правильно, а ты нет. А объяснять им, что все наоборот, бессмысленно.

        В проем если твое слово «рендер» означает только парсинг, то все нормально — пока визуальной части нет, юзеры разницы и не увидят :)


        1. lastmac
          13.09.2016 11:33
          +5

          Давайте всё же на вы. Рендер — это расчет, расчет всего до состояния «взял и нарисовал» + рисование в файл (по возможности), а вот браузер это уже отрисовка всего на экран со всеми полагающимися плюшками. Вы же понимаете, что рендер создается не зависимо от железки. На «любой железке» свой способ рисовать, вот кто этой самой железкой владеет тот и будет рисовать.

          Вы спецификации читали? Почему вы говорите, что основная сложность это парсить битый хтмл? Вы думаете текущий парсер (MyHTML) не умеет верно это парсить? IE тянет только свои древние баги, к которым пользователи привыкли. И думается мне, что они уже 100 раз не рады что когда-то эти баги допустили. Более того, их новый движок, вроде, этих багов уже с собой не тащит. Я не знаю случаев где хром или фф поддерживали бы баги ие, то есть то чего нет в спецификации, а вот из-за прихоти угодить ие.

          Я более не буду с вами спорить. Отвечу в вашем же манере, что я считаю грубым, — Скорее всего вы не очень понимаете о чём пишете.


          1. Durimar123
            13.09.2016 12:08

            Вот — как я и предполагал проблема в слове «рендерер HTML» для меня это отрисовка и UI. А для вас это расчет параметров из HTML + CSS.
            Не путайте людей, то что вы пишите это не редерер, это DOM — дерево объектов, возможно с ссылками на подходящие CSS стили.

            А сам по себе DOM вряд ли кому-то нужен.


            1. lastmac
              13.09.2016 12:13
              +3

              Простите, но путаете людей тут только вы. DOM — это DOM. Я говорю, более того я делаю, рендер HTML, если слова Render Tree/Layers вам что-то говорят то вы должны понимать. Я делаю довольно сложную «штуку», а DOM это малая часть этой «штуки».


              1. Durimar123
                13.09.2016 12:43
                +1

                Что-то вы меня запутали. Если рендер это отрисовка, а Tree/Layers это дерево/слои. То какое дерево и какие слои вы отрисовываете? и куда?

                «RenderHtml» это разве не отрисовка боксов, бордюров, текста, имеджей и т.д.? Что должен делать ваш рендер HTML?


                1. alibertino
                  14.09.2016 09:01
                  -1

                  А вы не путайтесь. Render и show или display — разные слова. Это расчет модели (положения элементов, их цвета и т.д.), а где она будет отображаться и как, другой вопрос.


                  1. Durimar123
                    14.09.2016 14:47
                    +2

                    Ре?ндеринг (англ. rendering — «визуализация») — термин в компьютерной графике, обозначающий процесс получения изображения

                    В прочем я уже понял, что данный проект имеет весьма косвенное отношение к HTML Browser, но остальные поняли автора именно так — парень делает с нуля HTML viewer!
                    Хотя по его же словам от делает «довольно сложную «штуку»». (забавные слова для программиста)
                    А зачем эта «сложная штука» нужна и что она будет делать в итоге, он так и не сказал.


                    1. alibertino
                      14.09.2016 14:59

                      Ну все верно, получение изображения, а не отображение его на конкретном устройстве. Парень все сказал, есть разные области отвественности, кто-то рендерит, а кто-то выводит на конкретный экран или в файл, например.
                      И для чего нужно, сто раз уже написано, для поддержки быстрого HTML на всех на свете устройствах, от часов до стиральных машин.


                      1. Durimar123
                        14.09.2016 15:08
                        +2

                        «Получение изображения, но не отображение..»
                        «Он рендерит, но не выводит ...»

                        Я правильно не понял твои слова? :)

                        Кто-то может мне объяснить, что на выходе дает этот модуль?


  1. yogurt1
    13.09.2016 00:15
    +1

    Интересный проект. Реально ли сделать аналог PhantomJS, но для вашего движка?


    1. lastmac
      13.09.2016 00:24

      Спасибо! Да, конечно, но лишь когда будет реализован JS и ещё не мало чего. В PhantomJS всегда раздражал тот факт, что нужно дождаться окончания полной загрузки страницы (выполнение всех скриптов и прочего). То есть, он может позволить себе висеть до 10-20 секунд прежде чем ему можно будет что-то отработать. Возможно там уже что-то поменялось, но раньше это был webkit с которым ты общаешься через JS. Я же хочу предоставить пользователю полный контроль, начиная от HTML дерева заканчивая Redner Tree с простым и понятным API.


      1. RPG18
        14.09.2016 21:36

        Там Qt WebKit, который можно расширять из C++.


  1. stychos
    13.09.2016 00:54
    +3

    Ни перед чем не останавливайтесь! Снимаю шляпу.


    1. lastmac
      13.09.2016 10:35

      Спасибо вам!


    1. lookid
      13.09.2016 13:22
      -1

      Ему останавливаться не перед чем. Там даже рендера и js нет. Это пишется за пару недель на OpenGL + scenegraph. Он пытается делать то, как раньше руками с нуля писали UI для игр. И делали это вполне успешно 1.5 человека.


  1. boom
    13.09.2016 10:23

    Блин, было бы супер, если бы его можно было приспособить для browser-less консольной прогонки тестов UI. Сейчас это phantomjs — но он ужасно медленный.


    1. lastmac
      13.09.2016 11:06

      Думается мне, как только движок достигнет адекватного состояния то это само собой возникнет.


  1. Holms
    13.09.2016 10:41

    на это смотрели? Весьма достойный конкурент.


    1. lastmac
      13.09.2016 11:04

      Привет, только вот вчера смотрел. Сложно с кем-то мёртвым конкурировать «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, крайне странно. Так же не понятно насколько покрывает спецификацию эта штука и какой версии.


  1. esata
    13.09.2016 15:12

    Могу только пожелать удачи!


    1. lastmac
      14.09.2016 09:44

      Спасибо!


  1. AirWorker
    14.09.2016 05:22

    Очень впечатляет! Мне кажется мало кто понимает то, насколько этот проект в случае успеха изменит мир.


    1. lookid
      14.09.2016 13:06
      -3

      Ничего он не изменит. Автор получит через 2-3 года клон IE 1.0, и всё. У тебя «нефтяной» максимализм, типа вот щас-щас вотчучуть и заживем, пендосы саснут, ря! Лучшебы автор V8 в 10 раз ускорил или еще чего. Или рендер у хрома, раз он его пишет.


      1. lastmac
        14.09.2016 14:35
        +7

        Не люблю отвечать на подобные комментарии, но исключение надо делать иногда.
        Вы видимо знающий человек в этой области. Ведь вы утверждаете, что полтора человека это могут сделать (где-то выше утверждали), то вот чётко уверены, что через два-три года будет клон IE 1.0. Вы и исходники все посмотрели, и спецификации все почитали, и знаете как всё устроено?

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

        Зачем мне идти и помогать гуглу, фаерфоксу? Там работают люди, программисты и прочие, которые получают за свою работу деньги, как и я собственно, а тут я должен всё бросить, и помогать какой-то зарубежной компании — зачем? Тем более в том продукте стратегию разработки которого я не разделяю с ними. Вы вот чем занимаетесь? Почему вы не помогаете гуглу? Вы видимо большой специалист в этой сфере, помогите гуглу, а то вдруг не успеете и он закроет проект.


  1. Crazy_as
    15.09.2016 07:12
    -1

    День добрый.
    Не подскажете, на чем GUI пишется? Будет ли порт под мобильные платформы?
    Спасибо.


    1. lastmac
      15.09.2016 17:42

      Простите, но я не делаю ГУИ. В статье всё написанно по этому поводу. А вот когда речь зайдет о браузере тогда и можно будет ответить на этот вопрос.


    1. lastmac
      15.09.2016 17:44

      А на мобильный платформах есть Си? Или вы хотите обвязку под конкретный язык? В статье все, вроде бы, написано.