but not all (for instance ). Listing out every valid child wasn't very elegant and certainly would cause problems for custom XHP components. Fortunately, the HTML spec categorized elements just for this purpose. Grouping elements into "block" or "inline" categories made validation far simpler. But if you've used XHP you might be wondering, "Why have I never needed to define my elements as inline or block before?" Well, the answer lies in how XHP renders an element tree. First it will render down all your custom elements into their eventual HTML primitives, then it will render the entire HTML primitive tree into a text string. The key here is that there are actually two passes, meaning XHP validates children in two sets: your elements first and then core HTML elements second. When you put a custom component inside of a element, you don't need to give it a category of %phrase (the HTML5 equivalent of %inline). When XHP renders the tree it will wait on validating the children of the root until its children are HTML elements. class :ui:hello-world extends :x:element { protected function render() { return Hello World!; } } $root =

; So when you render $root, XHP will first render the instance (which will produce the following node tree: Hello World!). Then it will render (and validate) the and elements. If we returned a
element from the :ui:hello-world::render method, then the validation would fail. So since we can use categories with free reign in our custom components, what pattern should we use? HTML groups elements by purpose, but it is my personal opinion that the best way to use categories is to group XHP elements by the type of their returned root node from render(). Let's look at an ex