[m-rev.] diff: fix Mantis bug 528
dirk at ziegemeyer.de
Sat Jan 30 07:46:07 AEDT 2021
> Am 29.01.2021 um 15:47 schrieb Zoltan Somogyi <zoltan.somogyi at runbox.com>:
> This should not need review.
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
a_href :: url,
a_children :: list(body_elem)
% Top-level body elements.
:- inst top_body_elem for body_elem/0
; 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
:- 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 …
More information about the reviews