sign не входит), тк я не беру изначально хеш от данных и есть вероятность, что для param_1 и param_2 существует такие param_3 и param_4, при которых param_1 + param_2 == param_3 + param_4, а у меня видимо паранойя. В PayU, например берутся подписываемые параметры и собираются как len(param_1) + param_1 + len(param_2) + param_2 + ....
Вот вы написали: .base .child и .base .child .node
А ведь может быть и:.base .childи.node
Т.е. .node может быть и внутри и снаружи.
.node будет внутри .base .child для правила .node, те это разные правила. Если же правило будет описано как .base .child .node, то уверенно можно сказать что оно никаким образом не будет применено к элементам .node находящимся вне .base .child .node.Да, я по второму варианту и хотел делать, вопрос только в эффективном и правильном поиске правил для заданного пути.
element#id.class в хорошем случае.div {...} div .node1 .node2 {...} div .node1 .node2 {} div a.node4 {}:div
.node1
.node2
.node3
a.node4
.node1, .node1 .node2, .node1 .node3 и a.node4 дня не div элементов и тд.div, поиск по элеметам внутри мы будем делать по корням (div плюс если нужно дефолтыне стили) плюс по правилам .node1 и a.node4..node1, то поиск будем делать по корнмя плюс предыдущий поиск .node1 и a.node4 плюс .node2 и .node3..node1, то поиск по .node2 и .node3 уже будет не нужен.div>p, div+p и div~p, но они не выглядят слишком сложными.
JSON.parse не вернет ошибки, то это полноценный JSON, если вернет, значит строка.