html_validation/lib.rs
1//! The html-validation crate provides method that can be used when validating html elements
2//! and attributes.
3//!
4//! The original goal of this crate was to be used as a dependency in procedural macros that
5//! validate html at compile time, but it is general purpose and can be used in other problem
6//! spaces.
7//!
8//! ## Potential Strategy - Pessimistic Validation
9//!
10//! We might make the html-validation crate is pessimistic by nature.
11//!
12//! This means that as we develop the create we'll blacklist more and more things - but in general
13//! we default to not saying that something is invalid until we've specifically encoded that it is
14//! not allowed.
15//!
16//! This means that you'll see methods with names like `is_definitely_invalid_child` - hinting
17//! that we're telling you that we're certain that the relationship is not allowed.
18//!
19//! Over time we'll cover more and more cases and this should become a non issue, but at the
20//! beginning it will mean that our validation is less strict than it should really be.
21//!
22//! The reason behind this strategy is that it lets people get up and running from day one without
23//! needing to wait until our validation is perfect.
24//! A downside is that as we become more and more strict there might be situations where you have
25//! to go back and tweak your html if you had something that we are now calling invalid.
26//!
27//! ## Potential Strategy - Optimistic Validation
28//!
29//! In this case we'd make html! generate a compile time error for anything that isn't certainly valid.
30//! Then there would be a second macro such as html_unstrict! that would be a bit more permissive.
31//!
32//! Over time as our validation permitted more cases people could use html! more and more instead of html_loose!
33
34#![deny(missing_docs)]
35
36pub use self_closing::is_self_closing;
37pub use svg_namespace::is_svg_namespace;
38pub use valid_tags::is_valid_tag;
39
40mod self_closing;
41mod svg_namespace;
42mod valid_tags;