Да, там достойный архитектор руку приложил.
Вот например вид на entrance hall (извиняюсь за качество, снимал iphon'ом)
Или вот «струнная тема» в интерьере
Помнится по последнему census 76 процентов тутошнего населения отметили свой mother tongue не английский или английский, но не канадский английский. Что означает — практически весь народ иммигранты в первом, втором, максимум третьем поколении.
«таджики» здесь вьетнамцы приезжающие по сезонным рабочим визам для работы на полях и пр. Да и то прав и обязанностей у них как и у всех остальных.
Буквально в 30 метрах от Rose Garden в UBC находится Chan Centre of Performing Arts.
Там проходит всяко разны студенческие торжества включая выдачу дипломов бакалаврам.
В остальное время Vancouver Symphony там устраивает концерты. Рекомендую посетить. Вельми достойно.
XPath в массе своей имеет computation complexity ранга P-hard т.е. O(Nk) где k это некое число явно больше 1.
Т.е. XPath можно использовать для скажем там однократного исполнения/обработки.
Но для ситуации CSS — набор правил описывающих состояние системы и система подверженна частым изменениям (UI events, etc.) — XPath явно тяжел.
Я не слышал ни разу что использование числа переносов в качестве метрики кем-то используется вообще. Перенос в тексте это настолько language specific feature что закладываться на нея в алгоритмах таблиц это путь в никуда.
Данный spring::engine используется для рассчета HTML таблиц в моих движках HTMLayout и Sciter. Он воспроизводит auto layout HTML таблиц достаточно точно насколько это вообще возможно ибо у всех browsing движков (trident, gecko и webkit) несколько разные базовые алгоритмы).
Извиняюсь, но я не понял фразу «столбец, состоящий в среднем из 2х коротких слов, но в одной строке содержащий 10 длинных, будет растянут гораздо больше, чем следовало.» «10 длинных» чего?
Во всяком случае все HTML движки согласны что вот эти две колонки имеют ширины 2:1
spring::engine::add(int valmin, int valmax, int weight)
и spring::engine::calc(int total_space)
Для каждого столбца таблицы зовем add c
valmin — минимальная ширина колонки без overflow.
valmax — или MAXINT или max-width если устанвленно.
weight — для флексов — flex units value, для таблиц либо процент если есть, либо привденный к процентам max-content width.
(max-content width это минимальная ширина блока в которм все параграфы в одну строку)
после вызова calc() с требуемой шириной таблицы получаем расситанные ширины столбцов.
Алгоритм финитный с хорошей сходимостью — макс. количество итераций N*N (где N это количество столбцов), но на практике просто N или 2N.
Что сейчас происходит при отработке hover события на скажем <a> элементе (мышь приехала на a):
1. сбросить текущий стиль a элемента и его descendants.
2. Найти новый стиль поддерева:
a. для всех С детей проверить все S правил (CSS) на предмет applicability к данному элементу.
b. если стиль поменялся сделать refresh региона занимаемого <a>
c. если новый стиль изменяет размеры то сделать relayout контейнера(ов).
Если же мы добавляем body! a:hover конструкцию то на каждое событие a:hover мы вынуждены делать a), b) и c) для всего дерева (документа). Причем возможных оптимизаций сего безобразия практически нет.
Скажем есть такие правила: a:link { border: none; }
body! > a:hover a:link { border-bottom:2px solid; }
Последнее правило читается так: «при mouse hover на любом <a> внутри документа установить border-bottom:2px для всех <a> в документе. Так как border-bottom:2px изменяет размер элемента то мы вынуждены не только пересчитать все стили <a> элементов в документе (а это full scan DOM tree+full window refresh) но и пересчитать layout всего документа. Т.е. тривиальный mouse move поверх документа скушает нашу батарейку весьма быстро.
Отличия: мои «CSS constants» это фактически иплементация аналогичной фичи из LESS. Крайне простая в иплементации, работает на уровне CSS парсера и не требует никаких изменений где либо еще. «CSS constants» имплементированы и активно используются в моих HTMLayout и Sciter.
«CSS variables» это на самом деле run-time фича — все properties которые используют некую CSS variable могут быть изменены путем изменения этой variable через CSSOM. Фича достатчно сложная в плане имплементации и требует доработки CSSOM.
Если принять общий набор use cases для CSS constants и variables за 100% то в 95% случаев «CSS constants» достаточно. Но как я понимаю народ все хочет найти perfect solution. Резюме: нескоро мы эту фичу иметь будем.
есть O(1) — если элемент <a> имеет :hover и он внутри <body> использовать данный стиль на нем.
Но вот здесь
body! a:hover {
background: red;
}
subject of the selector есть уже body элемент. Т.е. computational complexity определения стиля для <body> элемента
уже O(N) где N это количество DOM элементов внутри body. Т.е. для того чтобы определить стиль <body> элемента CSS processor будет вынужден сканировать всех DOM детей <body> вглубину.
В настоящее время сложность определения стилей всех элементов на странице есть O(N*S)
где
N — количество DOM элементов;
S — количество CSS rules.
Но с введением данной фичи сложность становится квадратичной O(N*N*S).
Что означает что первый же залетевший дятел («вебмастер Вован») разрушит цивилизацию. Хотите DDoS атак вашего любимого браузера? — их будет у вас.
Был когда-то старый добрый HTML desktop. Это когда окно десктопа был просто HTML со всеми плюшками.
Я бы ничего не выдумывал и сделал бы то же самое но с «metro engine» на этот раз. И никаких проблем. Хочешь видеть плитки — сверни все окна и гори оно огнем.
«Чтобы решить эту проблему нам пришлось разработать свой собственный протокол вызовов JavaScript из C#. Идея заключается в следующем:
1. для передачи параметров используется div с заданным идентификатором
2. C# сериализует имя и массив параметров для JavaScript функции в JSON строку и помещает ее в заданный div
3. JavaScript извлекает JSON, десериализует его и вызывает указанную функцию»
точно займет достойное место в коллекции.
Предполагается что это все еще и работает с удовлетворительной скоростью, да?
Заметь, в моем варианте нет вызова функции котороя есть в принципе дорогое удовольствие да и syntax noise наличествует. А так если есть желание то можно и так написать:
Но надо метод function Array.each(callback) {...} изобразить сначала.
Но как бы повторять jQuery задачи у меня не стояло изначально. Порт jQuery core в принципе пишется тривиально если есть такое желание. Моя нативная имплементация, кстати, наверное больше ближе к prototype.js чем к jQuery.
Ну не без проблем конечно. Про глючная не слышал особо.
Вот например Avast! использует HTMLayout. Вполне так все работает у них. Наверное готовить HTMLayout умеют ;-)
Вот конкретный вопрос был про то как сделать <input type="hex-number"> — элемент ввода шестнадцатеричных чисел с кнопками "+" и "-".
В sciter/htmlayout такое делается как тривиальная сборка такого input из трех стандартных lego блоков (DOM элементов): с behavior:edit плюс две кноки . Вот решение полностью.
В Qt например это можно рещить написанием класса отнаследованным от QAbstractSpinBox со всеми вытекающими.
Проблема в том что еще нужно знать что есть такой вот QAbstractSpinBox, исследовать что он может и т.д.
В Sciter, т.е. HTML/CSS/script задача разбивается на две независимые группы: нарисовать стили, создать DOM струкуру из универсальных кубиков и связать события/состояния между ними.
В чистом виде — нет, не портировал. Потребности не было.
JQuery селекторы имплементрованы нативно. А опять же за нативным методом Element.request() весь AJAX/JSON.
$( selector ) — возвращает первый элемент из документа удовлетвояющий селектору. elem.$( selector ) — то же только из под-дерева elem. $$( selector ) возвращает массив элементов удовлетвояющих селектору. Что-то сделать для всех таких элементов:
for( var elem in $$(ul#list > li) )
elem.state.visited = true;
Вот например вид на entrance hall (извиняюсь за качество, снимал iphon'ом)
Или вот «струнная тема» в интерьере
Помнится по последнему census 76 процентов тутошнего населения отметили свой mother tongue не английский или английский, но не канадский английский. Что означает — практически весь народ иммигранты в первом, втором, максимум третьем поколении.
«таджики» здесь вьетнамцы приезжающие по сезонным рабочим визам для работы на полях и пр. Да и то прав и обязанностей у них как и у всех остальных.
Там проходит всяко разны студенческие торжества включая выдачу дипломов бакалаврам.
В остальное время Vancouver Symphony там устраивает концерты. Рекомендую посетить. Вельми достойно.
Т.е. XPath можно использовать для скажем там однократного исполнения/обработки.
Но для ситуации CSS — набор правил описывающих состояние системы и система подверженна частым изменениям (UI events, etc.) — XPath явно тяжел.
Данный spring::engine используется для рассчета HTML таблиц в моих движках HTMLayout и Sciter. Он воспроизводит auto layout HTML таблиц достаточно точно насколько это вообще возможно ибо у всех browsing движков (trident, gecko и webkit) несколько разные базовые алгоритмы).
Извиняюсь, но я не понял фразу «столбец, состоящий в среднем из 2х коротких слов, но в одной строке содержащий 10 длинных, будет растянут гораздо больше, чем следовало.» «10 длинных» чего?
Во всяком случае все HTML движки согласны что вот эти две колонки имеют ширины 2:1
<table width="100%" border=1> <tr> <td>123456789012345 6789</td> <td>12345 1234</td> </tr> </table>Таблицы используют механизм сходный с flex layout
В той статье приведена моя имплеменация т.н. spring engine (Физическая инерпретация процесса — связанная системы пружин с ограничителями. )
www.terrainformatica.com/w3/flex-layout/spring-engine.h
Там два основных метода
spring::engine::add(int valmin, int valmax, int weight)и
spring::engine::calc(int total_space)Для каждого столбца таблицы зовем add c
valmin — минимальная ширина колонки без overflow.
valmax — или MAXINT или max-width если устанвленно.
weight — для флексов — flex units value, для таблиц либо процент если есть, либо привденный к процентам max-content width.
(max-content width это минимальная ширина блока в которм все параграфы в одну строку)
после вызова calc() с требуемой шириной таблицы получаем расситанные ширины столбцов.
Алгоритм финитный с хорошей сходимостью — макс. количество итераций N*N (где N это количество столбцов), но на практике просто N или 2N.
var children = elem.selectAll( ":root > *" );:root в Element.select это this элемент, и поиск всегда идет по поддереву — детям данного элемента.
siblings будет так
var siblings = elem.parent.selectAll( ":root > *" );document.querySelectorAll это глобальный поиск и иммеет крайне ограниченную функциональность из-за этого.
1. сбросить текущий стиль a элемента и его descendants.
2. Найти новый стиль поддерева:
a. для всех С детей проверить все S правил (CSS) на предмет applicability к данному элементу.
b. если стиль поменялся сделать refresh региона занимаемого <a>
c. если новый стиль изменяет размеры то сделать relayout контейнера(ов).
Если же мы добавляем
body! a:hoverконструкцию то на каждое событие a:hover мы вынуждены делать a), b) и c) для всего дерева (документа). Причем возможных оптимизаций сего безобразия практически нет.Скажем есть такие правила:
a:link { border: none; } body! > a:hover a:link { border-bottom:2px solid; }Последнее правило читается так: «при mouse hover на любом <a> внутри документа установить border-bottom:2px для всех <a> в документе. Так как border-bottom:2px изменяет размер элемента то мы вынуждены не только пересчитать все стили <a> элементов в документе (а это full scan DOM tree+full window refresh) но и пересчитать layout всего документа. Т.е. тривиальный mouse move поверх документа скушает нашу батарейку весьма быстро.
Еще про вычислительную сложность
Одна моя «CSS constants»: wiki.csswg.org/ideas/constants
и «CSS variables» изначально предложенная Daniel Glazman: dev.w3.org/csswg/css-variables/
Отличия: мои «CSS constants» это фактически иплементация аналогичной фичи из LESS. Крайне простая в иплементации, работает на уровне CSS парсера и не требует никаких изменений где либо еще. «CSS constants» имплементированы и активно используются в моих HTMLayout и Sciter.
«CSS variables» это на самом деле run-time фича — все properties которые используют некую CSS variable могут быть изменены путем изменения этой variable через CSSOM. Фича достатчно сложная в плане имплементации и требует доработки CSSOM.
Если принять общий набор use cases для CSS constants и variables за 100% то в 95% случаев «CSS constants» достаточно. Но как я понимаю народ все хочет найти perfect solution. Резюме: нескоро мы эту фичу иметь будем.
body a:hover { background: red; }есть O(1) — если элемент <a> имеет :hover и он внутри <body> использовать данный стиль на нем.
Но вот здесь
body! a:hover { background: red; }subject of the selector есть уже body элемент. Т.е. computational complexity определения стиля для <body> элемента
уже O(N) где N это количество DOM элементов внутри body. Т.е. для того чтобы определить стиль <body> элемента CSS processor будет вынужден сканировать всех DOM детей <body> вглубину.
В настоящее время сложность определения стилей всех элементов на странице есть O(N*S)
где
N — количество DOM элементов;
S — количество CSS rules.
Но с введением данной фичи сложность становится квадратичной O(N*N*S).
Что означает что первый же залетевший дятел («вебмастер Вован») разрушит цивилизацию. Хотите DDoS атак вашего любимого браузера? — их будет у вас.
Я бы ничего не выдумывал и сделал бы то же самое но с «metro engine» на этот раз. И никаких проблем. Хочешь видеть плитки — сверни все окна и гори оно огнем.
«Чтобы решить эту проблему нам пришлось разработать свой собственный протокол вызовов JavaScript из C#. Идея заключается в следующем:
1. для передачи параметров используется div с заданным идентификатором
2. C# сериализует имя и массив параметров для JavaScript функции в JSON строку и помещает ее в заданный div
3. JavaScript извлекает JSON, десериализует его и вызывает указанную функцию»
точно займет достойное место в коллекции.
Предполагается что это все еще и работает с удовлетворительной скоростью, да?
Но надо метод
function Array.each(callback) {...}изобразить сначала.Но как бы повторять jQuery задачи у меня не стояло изначально. Порт jQuery core в принципе пишется тривиально если есть такое желание. Моя нативная имплементация, кстати, наверное больше ближе к prototype.js чем к jQuery.
Вот например Avast! использует HTMLayout. Вполне так все работает у них. Наверное готовить HTMLayout умеют ;-)
Вот конкретный вопрос был про то как сделать
<input type="hex-number">— элемент ввода шестнадцатеричных чисел с кнопками "+" и "-".В sciter/htmlayout такое делается как тривиальная сборка такого input из трех стандартных lego блоков (DOM элементов): с behavior:edit плюс две кноки . Вот решение полностью.
В Qt например это можно рещить написанием класса отнаследованным от QAbstractSpinBox со всеми вытекающими.
Проблема в том что еще нужно знать что есть такой вот QAbstractSpinBox, исследовать что он может и т.д.
В Sciter, т.е. HTML/CSS/script задача разбивается на две независимые группы: нарисовать стили, создать DOM струкуру из универсальных кубиков и связать события/состояния между ними.
JQuery селекторы имплементрованы нативно. А опять же за нативным методом Element.request() весь AJAX/JSON.
$( selector )— возвращает первый элемент из документа удовлетвояющий селектору.elem.$( selector )— то же только из под-дерева elem.$$( selector )возвращает массив элементов удовлетвояющих селектору. Что-то сделать для всех таких элементов:Как бы даже и по-гуманнее будет, нет?
Хмм… точно помню писал ссылки. ок, еще раз тогда:
Sciter home. Там же и англоязычный форум.
Русскоязычный форум живет на RSDN. За что хлопцам оттуда большое человеческое спасибо.
Ну и Sciter2 SDK.