Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow custom elements in <head>? #53

Open
dmbaturin opened this issue Aug 31, 2023 · 1 comment
Open

Allow custom elements in <head>? #53

dmbaturin opened this issue Aug 31, 2023 · 1 comment

Comments

@dmbaturin
Copy link
Contributor

Right now, if lambdasoup encounters a non-standard element in <head>, it moves that element to <body>.

utop # Soup.parse {|<html> <head> <faketag content="no such element"> </head> <body> </body> </html> |} |> Soup.to_string ;;
- : string =
"<html><head> </head><body><faketag content=\"no such element\">     </faketag></body></html>"

For soupault, that means that it's impossible to write plugins that translate fake elements in <head> to real, valid HTML. For <body>, such an approach proved very fruitful — it serves the same role as "shortcodes" in other SSGs but it's a lot more flexible (see https://soupault.app/plugins/#augmented-html).

There are use cases for extending <head> in the same manner, but lambdasoup makes that impossible at the moment.

Do you think there could be an option to allow that, or that moving unusual elements to the body may be an overcorrection? Or are there problems that can only be solved by the current behavior that I fail to see?
@aantron
Copy link
Owner

aantron commented Sep 5, 2023

As I recall, this behavior is part of the error correction specified in the HTML5 spec. Disabling it as an option would have to be added to Markup.ml. I would probably merge a PR that does so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dmbaturin @aantron