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, если вернет, значит строка.