Specify what the line break converter should do and rewrite it in DOM

Subscribing - as is, the _filter_autop() function is very difficult to work with, and the upstream version isn't any better.

Part of this fix should be cleaning up the test cases so they have better descriptions; currently many of them just repeat "Make sure line breaking produces matching paragraph tags.", which isn't helpful when they fail.

I've been experimenting with the DOM in PHP and how it relates to #653988: Line break filter corrupts existing XHTML.

Using the DOM could result in a smarter line break filter, sure. The problem is that by using the DOM to read HTML, then serializing it later, we're "correcting" the HTML in much the same way that the HTML corrector filter is - there doesn't seem to be any way to use this approach to convert line breaks independently that I can yet discern.

Does this mean we need to merge the line break conversion functionality in with the HTML correction filter?

I understand that. Let me restate my comment perhaps a little bit clearer. We have two tasks which are currently (rightly) two separate filters: converting line breaks and cleaning HTML. The problem is that the mere act of calling filter_dom_load() means that whatever we're going to get from serializing it later is going to have clean HTML. That's great if we want to just clean HTML, or if we want to convert line breaks and clean HTML. However, if we want to just convert line breaks… I don't see how we can do that if we're using filter_dom_load() (or the DOM in general).

Nice context idea, Damien -- food for thought for http://drupal.org/project/filter

I think the tests for the line break filter should cover a range of expected behaviors already. That said, I'm not entirely sure whether it will be easy (or easier) to implement this filter via DOM manipulations...

Interesting... for D8 it would be interesting to have filters hook into distinct phases, such as pre-process (for markdown, etc.), DOM (where the hook takes a dom object instead of a string), and post-process. That would allow filters to not have to resort to regexp's when manipulating XHTML, but that would also mean that the HTML corrector filter would be unavoidably embedded in the processing scheme.

For D7 though, I think we should at least try to fix the line break filter. See http://drupal.org/node/653988#comment-2998364 for an example of how broken it is.

Damien and carlos, I think you're on the right track. Requiring the DOM to be used in the filtering process is a huge step that we need to consider, but I think the net benefit from doing so could ultimately be very great. carlos, you mention "post-process…" What do you envision there? Perhaps filters that work on the HTML after it's been serialized from the DOM object?

Something else we could gain from this approach is getting rid of the fail that is the filter rearranging page!

@Garrett, yes, phase 3 would be after filter_dom_serialize() is called, filters operating on HTML strings exactly like how they currently do. Filters would still need to be weighted though, and I'm not sure if that can let us get rid of a weighting interface either.

From my recent research, I think a DOM-based line break filter would be extremely hard to implement, without dramatically simplifying its scope. DOM makes it easy to iterate over (or ignore) the children of a specific element, but doing things like searching for whitespace in relation to block level tags would be seemingly impossible without regexp's. DOM might be good for other types of filters that have a more direct target (ala getElementsByTagName), so I think it might still be valuable to have a three-phase filter system.

For now I'm attempting to fix some of the shortcomings of our current filter at #653988: Line break filter corrupts existing XHTML

carlos, sure, filters will still need to be weighted, but I disagree about not being able to ditch the weighting interface. What does that do exactly, anyway? It helps make sure that filters like Markdown or Textile or BBcode run before filters which expect HTML input. With this three-phase approach, filters can more easily specify themselves where they should go in the process. Further weighting may be necessary beyond that, but it still doesn't need a user-facing interface - after all, "normal" modules have weights in the System table too, and there's no user-facing interface to reorder those (which is something that almost never needs to be done anyway).

I created #807996: [meta] Input filters and text formats for further discussion along these lines, and hopefully some action.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Since there's been no follow up and was tagged for summary update 10 years ago going to close out. If still valid please reopen

Thanks all