From fc87c009806dcc98867f6b58efe29b042aa01dee Mon Sep 17 00:00:00 2001 From: littleblack111 Date: Mon, 18 May 2026 23:10:59 +0800 Subject: node: update --- node_modules/@trysound/sax/README.md | 202 ----------------------------------- 1 file changed, 202 deletions(-) delete mode 100644 node_modules/@trysound/sax/README.md (limited to 'node_modules/@trysound/sax/README.md') diff --git a/node_modules/@trysound/sax/README.md b/node_modules/@trysound/sax/README.md deleted file mode 100644 index c43d2ac2..00000000 --- a/node_modules/@trysound/sax/README.md +++ /dev/null @@ -1,202 +0,0 @@ -# svg/sax - -A maintained fork of [sax-js](https://github.com/isaacs/sax-js) sax-style parser for XML and HTML. - -Designed with [node](http://nodejs.org/) in mind, but should work fine in -the browser or other CommonJS implementations. - -## What This Is - -* A very simple tool to parse through an XML string. -* A stepping stone to a streaming HTML parser. -* A handy way to deal with RSS and other mostly-ok-but-kinda-broken XML - docs. - -## What This Is (probably) Not - -* An HTML Parser - That's a fine goal, but this isn't it. It's just - XML. -* A DOM Builder - You can use it to build an object model out of XML, - but it doesn't do that out of the box. -* XSLT - No DOM = no querying. -* 100% Compliant with (some other SAX implementation) - Most SAX - implementations are in Java and do a lot more than this does. -* An XML Validator - It does a little validation when in strict mode, but - not much. -* A Schema-Aware XSD Thing - Schemas are an exercise in fetishistic - masochism. -* A DTD-aware Thing - Fetching DTDs is a much bigger job. - -## Regarding `Hello, world!').close(); -``` - - -## Arguments - -Pass the following arguments to the parser function. All are optional. - -`strict` - Boolean. Whether or not to be a jerk. Default: `false`. - -`opt` - Object bag of settings regarding string formatting. All default to `false`. - -Settings supported: - -* `trim` - Boolean. Whether or not to trim text and comment nodes. -* `normalize` - Boolean. If true, then turn any whitespace into a single - space. -* `lowercase` - Boolean. If true, then lowercase tag names and attribute names - in loose mode, rather than uppercasing them. -* `xmlns` - Boolean. If true, then namespaces are supported. -* `position` - Boolean. If false, then don't track line/col/position. -* `strictEntities` - Boolean. If true, only parse [predefined XML - entities](http://www.w3.org/TR/REC-xml/#sec-predefined-ent) - (`&`, `'`, `>`, `<`, and `"`) - -## Methods - -`write` - Write bytes onto the stream. You don't have to do this all at -once. You can keep writing as much as you want. - -`close` - Close the stream. Once closed, no more data may be written until -it is done processing the buffer, which is signaled by the `end` event. - -`resume` - To gracefully handle errors, assign a listener to the `error` -event. Then, when the error is taken care of, you can call `resume` to -continue parsing. Otherwise, the parser will not continue while in an error -state. - -## Members - -At all times, the parser object will have the following members: - -`line`, `column`, `position` - Indications of the position in the XML -document where the parser currently is looking. - -`startTagPosition` - Indicates the position where the current tag starts. - -`closed` - Boolean indicating whether or not the parser can be written to. -If it's `true`, then wait for the `ready` event to write again. - -`strict` - Boolean indicating whether or not the parser is a jerk. - -`opt` - Any options passed into the constructor. - -`tag` - The current tag being dealt with. - -And a bunch of other stuff that you probably shouldn't touch. - -## Events - -All events emit with a single argument. To listen to an event, assign a -function to `on`. Functions get executed in the this-context of -the parser object. The list of supported events are also in the exported -`EVENTS` array. - -`error` - Indication that something bad happened. The error will be hanging -out on `parser.error`, and must be deleted before parsing can continue. By -listening to this event, you can keep an eye on that kind of stuff. Note: -this happens *much* more in strict mode. Argument: instance of `Error`. - -`text` - Text node. Argument: string of text. - -`doctype` - The ``. Argument: -object with `name` and `body` members. Attributes are not parsed, as -processing instructions have implementation dependent semantics. - -`sgmldeclaration` - Random SGML declarations. Stuff like `` -would trigger this kind of event. This is a weird thing to support, so it -might go away at some point. SAX isn't intended to be used to parse SGML, -after all. - -`opentagstart` - Emitted immediately when the tag name is available, -but before any attributes are encountered. Argument: object with a -`name` field and an empty `attributes` set. Note that this is the -same object that will later be emitted in the `opentag` event. - -`opentag` - An opening tag. Argument: object with `name` and `attributes`. -In non-strict mode, tag names are uppercased, unless the `lowercase` -option is set. If the `xmlns` option is set, then it will contain -namespace binding information on the `ns` member, and will have a -`local`, `prefix`, and `uri` member. - -`closetag` - A closing tag. In loose mode, tags are auto-closed if their -parent closes. In strict mode, well-formedness is enforced. Note that -self-closing tags will have `closeTag` emitted immediately after `openTag`. -Argument: tag name. - -`attribute` - An attribute node. Argument: object with `name` and `value`. -In non-strict mode, attribute names are uppercased, unless the `lowercase` -option is set. If the `xmlns` option is set, it will also contains namespace -information. - -`comment` - A comment node. Argument: the string of the comment. - -`opencdata` - The opening tag of a ``) of a `` tags trigger a `"script"` -event, and their contents are not checked for special xml characters. -If you pass `noscript: true`, then this behavior is suppressed. - -## Reporting Problems - -It's best to write a failing test if you find an issue. I will always -accept pull requests with failing tests if they demonstrate intended -behavior, but it is very hard to figure out what issue you're describing -without a test. Writing a test is also the best way for you yourself -to figure out if you really understand the issue you think you have with -sax-js. -- cgit v1.2.3