Philip Sampaio

Hi @fakenickels :wave: I don't know yet how to solve on the lexer/parser level, but there is a way that works today: you can create a `Floki.Selector` by hand. ```elixir...

@inoas this is good idea. Maybe `:custom_self_closing_tags`? > If this interestes you: Would you also prefer for this to be changable at runtime like the html parser is? This would...

I personally don't see much use for replacing them entirely. Seems like only appending is enough.

Yeah, this is a bug :/ It won't be fixed easily because of https://github.com/philss/floki/issues/37 But at least we are half way there https://github.com/philss/floki/projects/2

@derek-zhou It's not that is too fragile, but I think the HTML parsing state machine is too damn complicated to fix when the parser never followed the specs :sweat_smile: I...

@derek-zhou I see. You can use both if you need. Just pass the parser as an option to `parse_document`.

This would be a nice feature! I think `inputs: true` is better. Since we need to consider the `select` and `radio` tags, maybe `form_values: true` could be a better name....

Hey @gbrlmtrz :wave: Thanks for open the issue. I think this is a problem in FastHTML. Maybe the parser doesn't support templates yet. I will try to confirm this week.

Hey @revati :wave: You actually can archive similar results using a _descendant combinator_ with the "all" selector ("`*`"). Please try: ```elixir "Some" |> Floki.parse_document!() |> Floki.find("div *:fl-contains('Some')") |> IO.inspect(label: :second)...

@andyleclair Thank you for opening the issue. This is a problem that we have because we don't consider parsing fragments as something different, when we should. html5ever's parses fragments as...