[m-rev.] diff: fix Mantis bug 528

[Dirk Ziegemeyer]

Hi Zoltan,

> Am 29.01.2021 um 15:47 schrieb Zoltan Somogyi <zoltan.somogyi at runbox.com>:
> 
> This should not need review.
> 
> Zoltan.<Log.bug528><DIFF.bug528>_______________________________________________

Thank you for creating a fix so quickly and for your advice to represent an html <ul> tag at type-level without insts.

I considered insts to be a good solution, because:

1. They allow syntactic sugar for lists: [] (which I am not aware of for the one_or_more type or similar representations)

2. There is one more HTML validation rule that can be enforced with insts easily: Nesting of <a> tags is not allowed. Neither direct nor indirect siblings may be <a> tags. I just have to create an inst with all top-level html tags except the <a> tag for this.


    % Elements that are allowed inside the body tag of an HTML document
    %
:- type body_elem
    --->    h1(list(body_elem))
    ;       h2(list(body_elem))
    ;       a(
                a_href      :: url,
                a_children  :: list(body_elem)
            )
    ;       ...


    % Top-level body elements.
    %
:- inst top_body_elem for body_elem/0
    --->    h1(non_empty_list(top_body_elem))
    ;       h2(non_empty_list(top_body_elem))
    ;       a(ground, non_empty_list(a_children)) % disallows nested links
    ;       ...


    % Contains all top-level body elements except the <a> tag.
    %
:- inst a_children for body_elem/0
    --->    h1(non_empty_list(a_children))
    ;       h2(non_empty_list(a_children))
    ;       ...


:- inst non_empty_list(I) for list/1
    --->    [I | list_skel(I)].


I guess it would be more effort to implement this validation rule at type-level.

My goal is to have a type- (and maybe inst-) level representation of HTML and CSS that allows easy writing and refactoring of web pages. I don't need a guarantee for all types of HTML validations if the effort-to-benefit-ratio is poor. Any improvement on my current workflow/toolset would be good. Especially:
- Write valid HTML and CSS with compiler-support
- Allowing modern, responsive and mobile-first design
- No more fiddling around with CSS
- No CSS preprocessors any more
- No need to include third-party CSS frameworks
- Less risk to break search engine optimisations during refactoring

I will see how far I will get …

Dirk