Changes

[mattesmohr]

Structure

I have resorted the files. For example:

|-- Source
|   |-- External (HTML)
|   |   |-- Attributes
|   |   |-- Elements
|   |   |-- Functions
|   |   |-- Types
|   |-- Internal (HTMLKit)
|   |   |-- HTMLKit

The External-Folder contains all the HTML specifications, we try to mirror.

The Internal-Folder contains everything, wich makes HTMLKit work in the background.

The Attributes-File contains the official attributes.

@MatsMoll: Not sure if we want support browser-specific attributes?

The Elements-File contains the official tags.

@MatsMoll: Not sure if we want to support unofficial or deprecated tags too? Is it possible to mark some tags deprecated as the consortium decide to not support them anymore in the future?

The Functions-File contains the custom functions, the people use

The Types-File collects every type. Mostly used by the type-Attribute. I have tried to use enum as a namespace, when a type contains more then one category. For Example:

public enum MediaType {
    
    public enum Common: String {
        
        case html = "text/html"
        case css = "text/css"
    }
    
    public enum Style: String {
        
        case css = "text/css"
    }
    
    public enum Source: String {
        
        case ogg = "video/ogg"
        case mp4 = "video/mp4"
        case webm = "video/webm"
        case mpeg = "audio/mpeg"
    }
    
    public enum Script: String {
        
        case javascript = "application/javascript"
    }
}

The Types-Files should not contain internal types!

Everything in the Internal-Folder should be bundled up in my opinion. I think it is not necessary to create files for every element, tag or attribute. It would increase the package size and I am not sure, if we have a goal here to stay slim.

Renaming

I have renamed a bunch of items to stick to the official terms.

ContentNode became NormalElement.

public protocol NormalElement: AttributeNode { ... }

@MatsMoll We could use the term "ContentElement", if you think it fits better.

DatableNode became EmptyElement.

public protocol EmptyElement: AttributeNode { ... }

Since NormalElement renders <tag></tag>. EmptyElement renders <tag />. There could possibly be a third element for <tag>. But honestly I haven't done much research on it.

HTML became HTMLContent

public protocol HTMLContent { ... }

Aliases

The <form> element for example would have a lot of protocols, so I tried to follow the example of

typealias Codable = Decodable & Encodable

and combine the attribute protocols. For example:

/// Alias to compine the protocols for `action`, `method`,  `encoding`, `target`, `name`.
///
///  e. g. `<form>`
///
public typealias Submittable = ActionAttribute & MethodAttribute & EncodingAttribute & TargetAttribute & NameAttribute

Instead of combining multiple functions in one protocol like we did in the past:

public protocol ValueableAttribute {
    func max(value: HTML) -> Self
    func min(value: HTML) -> Self
    func value(_ value: HTML) -> Self
}

@MatsMoll Not sure here if my way is the best way.

Well for now, I think I got all changes. I am open for discussion as always.

I am offline for one week now. So take your time. :-)

[MatsMoll]

Some very good points here, and I agree with the changes you suggest! 😄

When it comest to supporting browser specific tags, there I am a bit unsure about what to do. However, I think it makes sense to support all the official and only add @depricated to existing tags? Thereby not adding more code that needs unwanted maintenance.

I also like ContentElement the best. Or at least some name that indicates it contains some content / child nodes. While EmptyElement makes me think it contains nothing, which is not quite correct. So maybe something like LeafElement, thereby indicating it can not contain any children.

And lastly, the combined protocol is more flexible, so if all the different sub-protocols makes sense to have separate as well, then I see that as the preferred design.

[mattesmohr]

When it comest to supporting browser specific tags, there I am a bit unsure about what to do. However, I think it makes sense to support all the official and only add @depricated to existing tags? Thereby not adding more code that needs unwanted maintenance.

Yup, you are right. We should avoid unwanted maintenance. Good point!

I also like ContentElement the best. Or at least some name that indicates it contains some content / child nodes. While EmptyElement makes me think it contains nothing, which is not quite correct. So maybe something like LeafElement, thereby indicating it can not contain any children.

I think here you mixed something up. EmptyElement was meant for tags without content. So it would describe it right. I go with ContentElement and EmptyElement. We can change it anytime.

[mattesmohr]

I have another idea to this specific code. See also: Discussion "Nodes"

[MatsMoll]

Also one ting on the MediaType. Would it be more flexible to describe the enums as a StringRepresentable struct? Thereby making it possible to define custom media types in case we have not added them.

It is a bit more code to get working, so is it worth it?

E.g something like this:

public enum MediaType {
    
    public struct Common: StringRepresentable {
        
        let mediaType: String

        init(stringLiteral: String) {
            self.mediaType = stringLiteral
        }

        public static let html: MediaType.Common = "text/html"
        public static let css: MediaType.Common = "text/css"
    }
}

[mattesmohr]

Thats a good idea! I will check.