hyper-html-api 0.5.2 → 0.6.3

package/conformance/MANIFEST.json

@@ -0,0 +1,6 @@
+{
+  "engine": "0.6.0",
+  "cheerio": "1.2.0",
+  "cases": 33,
+  "note": "Versions the expectations were generated against. Parity means parity with THIS pair; regenerate deliberately, never as a side effect of an install."
+}

package/conformance/cases/basic-scalar-and-list.expected.json

@@ -0,0 +1,7 @@
+{
+  "title": "Hello",
+  "items": [
+    "one",
+    "two"
+  ]
+}

package/conformance/cases/basic-scalar-and-list.html

@@ -0,0 +1,4 @@
+<!doctype html><html><body>
+<h1>Hello</h1>
+<ul><li class="i">one</li><li class="i">two</li></ul>
+</body></html>

package/conformance/cases/basic-scalar-and-list.meta

@@ -0,0 +1,4 @@
+tier: 1
+face: query
+expect: ok
+note: The happy path. Scalar selector, [] list form, relaxed unquoted keys.

package/conformance/cases/basic-scalar-and-list.parsed.json

@@ -0,0 +1,4 @@
+{
+  "title": "h1",
+  "items": ".i[]"
+}

package/conformance/cases/basic-scalar-and-list.rules

@@ -0,0 +1 @@
+{title:"h1",items:".i[]"}

package/conformance/cases/cms-template-skipped-by-default.expected.json

@@ -0,0 +1,7 @@
+{
+  "plain": [
+    "one"
+  ],
+  "self": [],
+  "descendant": []
+}

package/conformance/cases/cms-template-skipped-by-default.html

@@ -0,0 +1,7 @@
+<!doctype html><html><body>
+<ul>
+<li class="plain">one</li>
+<li class="self" cms-template>seed</li>
+<li cms-template><span class="descendant">nested</span></li>
+</ul>
+</body></html>

package/conformance/cases/cms-template-skipped-by-default.meta

@@ -0,0 +1,7 @@
+tier: 1
+face: query
+expect: ok
+note: [cms-template] is excluded from find() BY DEFAULT, no opt-in, because a seed row is not
+note: data for any consumer. The test is closest(), so it is ancestor-or-self: the marked li
+note: drops out and so does a plain span nested inside a marked li. That is wider than the
+note: rules-tag filter, which only ever tests the matched node itself.

package/conformance/cases/cms-template-skipped-by-default.parsed.json

@@ -0,0 +1,5 @@
+{
+  "plain": ".plain[]",
+  "self": ".self[]",
+  "descendant": ".descendant[]"
+}

package/conformance/cases/cms-template-skipped-by-default.rules

@@ -0,0 +1 @@
+{"plain":".plain[]","self":".self[]","descendant":".descendant[]"}

package/conformance/cases/depth-at-limit-ok.expected.json

@@ -0,0 +1,41 @@
+{
+  "a": {
+    "a": {
+      "a": {
+        "a": {
+          "a": {
+            "a": {
+              "a": {
+                "a": {
+                  "a": {
+                    "a": {
+                      "a": {
+                        "a": {
+                          "a": {
+                            "a": {
+                              "a": {
+                                "a": {
+                                  "a": {
+                                    "a": {
+                                      "a": {
+                                        "a": "Hello"
+                                      }
+                                    }
+                                  }
+                                }
+                              }
+                            }
+                          }
+                        }
+                      }
+                    }
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

package/conformance/cases/depth-at-limit-ok.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<h1>Hello</h1>
+</body></html>

package/conformance/cases/depth-at-limit-ok.meta

@@ -0,0 +1,6 @@
+tier: 1
+face: query
+expect: ok
+note: The limit is exact. MAX_RULE_DEPTH is 20 and the guard is `depth > 20`, and the root rule
+note: is visited at depth 0, so 20 nested objects put the leaf string at depth 20 and it still
+note: extracts. One more object throws; see depth-exceeded.

package/conformance/cases/depth-at-limit-ok.parsed.json

@@ -0,0 +1,41 @@
+{
+  "a": {
+    "a": {
+      "a": {
+        "a": {
+          "a": {
+            "a": {
+              "a": {
+                "a": {
+                  "a": {
+                    "a": {
+                      "a": {
+                        "a": {
+                          "a": {
+                            "a": {
+                              "a": {
+                                "a": {
+                                  "a": {
+                                    "a": {
+                                      "a": {
+                                        "a": "h1"
+                                      }
+                                    }
+                                  }
+                                }
+                              }
+                            }
+                          }
+                        }
+                      }
+                    }
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

package/conformance/cases/depth-at-limit-ok.rules

@@ -0,0 +1 @@
+{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:"h1"}}}}}}}}}}}}}}}}}}}}

package/conformance/cases/depth-exceeded-path-contains-selector.error.json

@@ -0,0 +1,5 @@
+{
+  "type": "MaxRuleDepthExceeded",
+  "message": "rule depth exceeded 20 at path: selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector.selector",
+  "status": 400
+}

package/conformance/cases/depth-exceeded-path-contains-selector.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<h1>Hello</h1>
+</body></html>

package/conformance/cases/depth-exceeded-path-contains-selector.meta

@@ -0,0 +1,9 @@
+tier: 3
+face: query
+expect: error
+note: DIVERGENCE. Byte-for-byte the same MaxRuleDepthExceeded as depth-exceeded, at the same
+note: depth, differing only in that the rule key is named `selector`, which puts the word into
+note: the message path. The JS hosts classify by sniffing the message, so this answers 400 while
+note: depth-exceeded answers 500. A host that maps by error TYPE gives both cases one status,
+note: so it must differ from the JS reference on one of the pair: 500 here, or 400 there.
+note: Direction: the data in the rule keys is steering the HTTP status.

package/conformance/cases/depth-exceeded-path-contains-selector.parsed.json

@@ -0,0 +1,43 @@
+{
+  "selector": {
+    "selector": {
+      "selector": {
+        "selector": {
+          "selector": {
+            "selector": {
+              "selector": {
+                "selector": {
+                  "selector": {
+                    "selector": {
+                      "selector": {
+                        "selector": {
+                          "selector": {
+                            "selector": {
+                              "selector": {
+                                "selector": {
+                                  "selector": {
+                                    "selector": {
+                                      "selector": {
+                                        "selector": {
+                                          "selector": "h1"
+                                        }
+                                      }
+                                    }
+                                  }
+                                }
+                              }
+                            }
+                          }
+                        }
+                      }
+                    }
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

package/conformance/cases/depth-exceeded-path-contains-selector.rules

@@ -0,0 +1 @@
+{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:{selector:"h1"}}}}}}}}}}}}}}}}}}}}}

package/conformance/cases/depth-exceeded.error.json

@@ -0,0 +1,5 @@
+{
+  "type": "MaxRuleDepthExceeded",
+  "message": "rule depth exceeded 20 at path: a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a",
+  "status": 500
+}

package/conformance/cases/depth-exceeded.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<h1>Hello</h1>
+</body></html>

package/conformance/cases/depth-exceeded.meta

@@ -0,0 +1,6 @@
+tier: 1
+face: query
+expect: error
+note: 21 nested objects put the leaf at depth 21 and MaxRuleDepthExceeded throws, one level past
+note: depth-at-limit-ok. The message carries the full key path. It contains neither "JSON" nor
+note: "selector", so the reference host answers 500 for what is really a malformed request.

package/conformance/cases/depth-exceeded.parsed.json

@@ -0,0 +1,43 @@
+{
+  "a": {
+    "a": {
+      "a": {
+        "a": {
+          "a": {
+            "a": {
+              "a": {
+                "a": {
+                  "a": {
+                    "a": {
+                      "a": {
+                        "a": {
+                          "a": {
+                            "a": {
+                              "a": {
+                                "a": {
+                                  "a": {
+                                    "a": {
+                                      "a": {
+                                        "a": {
+                                          "a": "h1"
+                                        }
+                                      }
+                                    }
+                                  }
+                                }
+                              }
+                            }
+                          }
+                        }
+                      }
+                    }
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

package/conformance/cases/depth-exceeded.rules

@@ -0,0 +1 @@
+{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:{a:"h1"}}}}}}}}}}}}}}}}}}}}}

package/conformance/cases/props-boolean-on-any-element.expected.json

@@ -0,0 +1,5 @@
+{
+  "checked": "false",
+  "selected": "false",
+  "disabled": "false"
+}

package/conformance/cases/props-boolean-on-any-element.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<div id="d">plain</div>
+</body></html>

package/conformance/cases/props-boolean-on-any-element.meta

@@ -0,0 +1,7 @@
+tier: 1
+face: query
+expect: ok
+note: The boolean-attribute names answer "false" on ANY element, not null. cheerio's prop()
+note: recognizes checked/selected/disabled by name alone, with no check that the element could
+note: carry them, so a plain div reports a definite "false" where every other absent property
+note: reports null. The absent-vs-false distinction is lost.

package/conformance/cases/props-boolean-on-any-element.parsed.json

@@ -0,0 +1,5 @@
+{
+  "checked": "#d@checked",
+  "selected": "#d@selected",
+  "disabled": "#d@disabled"
+}

package/conformance/cases/props-boolean-on-any-element.rules

@@ -0,0 +1 @@
+{"checked":"#d@checked","selected":"#d@selected","disabled":"#d@disabled"}

package/conformance/cases/props-empty-attr-vs-empty-prop.expected.json

@@ -0,0 +1,4 @@
+{
+  "emptyAttr": null,
+  "emptyProp": ""
+}

package/conformance/cases/props-empty-attr-vs-empty-prop.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<div id="d" class="" data-empty=""></div>
+</body></html>

package/conformance/cases/props-empty-attr-vs-empty-prop.meta

@@ -0,0 +1,6 @@
+tier: 1
+face: query
+expect: ok
+note: Empty reads split by route. An ordinary attribute goes through `return v ? v : null`, so
+note: an empty attribute is indistinguishable from a missing one and reads null. A whitelisted
+note: property goes through `v == null ? null : String(v)`, so class="" survives as "".

package/conformance/cases/props-empty-attr-vs-empty-prop.parsed.json

@@ -0,0 +1,4 @@
+{
+  "emptyAttr": "#d@data-empty",
+  "emptyProp": "#d@className"
+}

package/conformance/cases/props-empty-attr-vs-empty-prop.rules

@@ -0,0 +1 @@
+{"emptyAttr":"#d@data-empty","emptyProp":"#d@className"}

package/conformance/cases/props-null-set.expected.json

@@ -0,0 +1,9 @@
+{
+  "dataset": null,
+  "classList": null,
+  "childElementCount": null,
+  "baseURI": null,
+  "offsetWidth": null,
+  "documentURI": null,
+  "contentType": null
+}

package/conformance/cases/props-null-set.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<div id="d" data-k="v"><span>child</span></div>
+</body></html>

package/conformance/cases/props-null-set.meta

@@ -0,0 +1,7 @@
+tier: 1
+face: query
+expect: ok
+note: Seven whitelisted names that cheerio cannot answer. They are on the DOM property list, so
+note: the read never falls back to attr(); cheerio's prop() has no value for them and returns
+note: undefined, which readPropOrAttr turns into null. Layout and document metadata are all in
+note: this set, so they read null on any server host, never 0 and never "".

package/conformance/cases/props-null-set.parsed.json

@@ -0,0 +1,9 @@
+{
+  "dataset": "#d@dataset",
+  "classList": "#d@classList",
+  "childElementCount": "#d@childElementCount",
+  "baseURI": "#d@baseURI",
+  "offsetWidth": "#d@offsetWidth",
+  "documentURI": "#d@documentURI",
+  "contentType": "#d@contentType"
+}

package/conformance/cases/props-null-set.rules

@@ -0,0 +1 @@
+{"dataset":"#d@dataset","classList":"#d@classList","childElementCount":"#d@childElementCount","baseURI":"#d@baseURI","offsetWidth":"#d@offsetWidth","documentURI":"#d@documentURI","contentType":"#d@contentType"}

package/conformance/cases/props-readonly-always-false.expected.json

@@ -0,0 +1,4 @@
+{
+  "set": "false",
+  "unset": "false"
+}

package/conformance/cases/props-readonly-always-false.html

@@ -0,0 +1,4 @@
+<!doctype html><html><body>
+<input id="t" readonly>
+<input id="u">
+</body></html>

package/conformance/cases/props-readonly-always-false.meta

@@ -0,0 +1,11 @@
+tier: 3
+face: query
+expect: ok
+skip: htmlclay=ships @readOnly fixed; fixed behavior asserted in htmlclay dataapi/props_test.go
+note: @readOnly is always the string "false". The name is whitelisted, so the read goes through
+note: prop(), which looks the name up in the attribs map, where the parser has already lowercased
+note: it to `readonly`. The whitelist spelling can never match, so the boolean-attribute fallback
+note: reports absent. Set and unset inputs are indistinguishable.
+note: DIVERGENCE, direction JS-only. This case pins the WART so an upstream fix gets noticed.
+note: htmlclay deliberately does not reproduce it and folds the name for the presence test, so a
+note: readonly input reports "true".

package/conformance/cases/props-readonly-always-false.parsed.json

@@ -0,0 +1,4 @@
+{
+  "set": "#t@readOnly",
+  "unset": "#u@readOnly"
+}

package/conformance/cases/props-readonly-always-false.rules

@@ -0,0 +1 @@
+{"set":"#t@readOnly","unset":"#u@readOnly"}

package/conformance/cases/props-select-textarea-value-null.expected.json

@@ -0,0 +1,5 @@
+{
+  "select": null,
+  "textarea": null,
+  "input": "v"
+}

package/conformance/cases/props-select-textarea-value-null.html

@@ -0,0 +1,5 @@
+<!doctype html><html><body>
+<select id="s"><option value="a">A</option><option value="b" selected>B</option></select>
+<textarea id="ta">hello</textarea>
+<input id="in" value="v">
+</body></html>

package/conformance/cases/props-select-textarea-value-null.meta

@@ -0,0 +1,8 @@
+tier: 3
+face: query
+expect: ok
+note: DIVERGENCE. cheerio reads @value out of the attribs map, and neither a select nor a
+note: textarea has a value ATTRIBUTE, so both read null on this host. In a browser the DOM
+note: adapter reads live properties: select@value is the selected option's value ("b") and
+note: textarea@value is its text ("hello"). Direction: server null, browser a real string.
+note: An input, whose value IS an attribute, agrees on both sides and is included as the control.

package/conformance/cases/props-select-textarea-value-null.parsed.json

@@ -0,0 +1,5 @@
+{
+  "select": "#s@value",
+  "textarea": "#ta@value",
+  "input": "#in@value"
+}

package/conformance/cases/props-select-textarea-value-null.rules

@@ -0,0 +1 @@
+{"select":"#s@value","textarea":"#ta@value","input":"#in@value"}

package/conformance/cases/props-tagname-and-nodetype.expected.json

@@ -0,0 +1,5 @@
+{
+  "tagName": "DIV",
+  "nodeName": "DIV",
+  "nodeType": "1"
+}

package/conformance/cases/props-tagname-and-nodetype.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<div id="d">x</div>
+</body></html>

package/conformance/cases/props-tagname-and-nodetype.meta

@@ -0,0 +1,6 @@
+tier: 1
+face: query
+expect: ok
+note: @tagName and @nodeName both uppercase, matching the DOM. @nodeType is the string "1", not
+note: the number 1: readPropOrAttr String()s every property read, so the numeric node type
+note: arrives as text and a consumer comparing it to 1 fails.

package/conformance/cases/props-tagname-and-nodetype.parsed.json

@@ -0,0 +1,5 @@
+{
+  "tagName": "#d@tagName",
+  "nodeName": "#d@nodeName",
+  "nodeType": "#d@nodeType"
+}

package/conformance/cases/props-tagname-and-nodetype.rules

@@ -0,0 +1 @@
+{"tagName":"#d@tagName","nodeName":"#d@nodeName","nodeType":"#d@nodeType"}

package/conformance/cases/props-type-is-node-type.expected.json

@@ -0,0 +1,5 @@
+{
+  "input": "tag",
+  "script": "script",
+  "style": "style"
+}

package/conformance/cases/props-type-is-node-type.html

@@ -0,0 +1,5 @@
+<!doctype html><html><body>
+<input id="t" type="text">
+<script id="s">var a = 1;</script>
+<style id="y">.a{}</style>
+</body></html>

package/conformance/cases/props-type-is-node-type.meta

@@ -0,0 +1,11 @@
+tier: 3
+face: query
+expect: ok
+skip: htmlclay=ships @type fixed; fixed behavior asserted in htmlclay dataapi/props_test.go
+note: @type is NOT the type attribute. `type` is on the DOM property whitelist, and domhandler
+note: nodes already carry a `type` field naming the node kind, so cheerio's prop() returns that
+note: instead: "tag" for a normal element, "script" for a script, "style" for a style. Three
+note: values, none of them the author's type="text".
+note: DIVERGENCE, direction JS-only. This case pins the WART so an upstream fix gets noticed.
+note: htmlclay deliberately does not reproduce it and returns the type attribute, because that API
+note: has no existing htmlclay users and preserving the bug would buy nothing.

package/conformance/cases/props-type-is-node-type.parsed.json

@@ -0,0 +1,5 @@
+{
+  "input": "#t@type",
+  "script": "#s@type",
+  "style": "#y@type"
+}

package/conformance/cases/props-type-is-node-type.rules

@@ -0,0 +1 @@
+{"input":"#t@type","script":"#s@type","style":"#y@type"}

package/conformance/cases/rules-duplicate-keys-last-wins.expected.json

@@ -0,0 +1,3 @@
+{
+  "a": "one"
+}

package/conformance/cases/rules-duplicate-keys-last-wins.html

@@ -0,0 +1,4 @@
+<!doctype html><html><body>
+<h1>Hello</h1>
+<ul><li class="i">one</li><li class="i">two</li></ul>
+</body></html>

package/conformance/cases/rules-duplicate-keys-last-wins.meta

@@ -0,0 +1,5 @@
+tier: 1
+face: query
+expect: ok
+note: Duplicate keys are not rejected. The tokenizer re-emits both, and JSON.parse keeps the
+note: LAST one, so the "h1" rule is silently discarded and the output holds the .i text.

package/conformance/cases/rules-duplicate-keys-last-wins.parsed.json

@@ -0,0 +1,3 @@
+{
+  "a": ".i"
+}

package/conformance/cases/rules-duplicate-keys-last-wins.rules

@@ -0,0 +1 @@
+{a:"h1",a:".i"}

package/conformance/cases/rules-iterate-dot-leading-works.expected.json

@@ -0,0 +1,10 @@
+{
+  "nav": [
+    {
+      "t": "Alpha"
+    },
+    {
+      "t": "Beta"
+    }
+  ]
+}

package/conformance/cases/rules-iterate-dot-leading-works.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<nav><a class="nav-item" href="/a">Alpha</a><a class="nav-item" href="/b">Beta</a></nav>
+</body></html>

package/conformance/cases/rules-iterate-dot-leading-works.meta

@@ -0,0 +1,6 @@
+tier: 1
+face: query
+expect: ok
+note: The contrast case for the two rules-iterate-lookahead-* bugs. `.` is not in /[a-zA-Z_]/,
+note: so the lookahead pushes a real BRACKET_OPEN and the iterate form parses as the pair it
+note: looks like. Whether iteration works at all depends on the first character of its selector.

package/conformance/cases/rules-iterate-dot-leading-works.parsed.json

@@ -0,0 +1,8 @@
+{
+  "nav": [
+    ".nav-item",
+    {
+      "t": "."
+    }
+  ]
+}

package/conformance/cases/rules-iterate-dot-leading-works.rules

@@ -0,0 +1 @@
+{nav:[.nav-item,{t:.}]}

package/conformance/cases/rules-iterate-lookahead-quoted.error.json

@@ -0,0 +1,5 @@
+{
+  "type": "RulesParseError",
+  "message": "Invalid extraction rules syntax: Expected ',' or '}' after property value in JSON at position 21 (line 1 column 22)",
+  "status": 400
+}

package/conformance/cases/rules-iterate-lookahead-quoted.html

@@ -0,0 +1,3 @@
+<!doctype html><html><body>
+<form id="f" action="/go"><input id="q" name="q"></form>
+</body></html>