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.

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

Update pod2html to output HTML5 instead of XHTML #17987

Closed
wants to merge 17 commits into from

Conversation

scottchiefbaker
Copy link
Contributor

This should address issue #17986.

This commit is best viewed with whitespace ignored. I normalized the line endings to not have trailing whitespace, and it makes the diff noisier than it really is.

@jkeenan
Copy link
Contributor

jkeenan commented Jul 20, 2020

Is your subject line for the Issue correct? I would think the update would be for pod2html rather than pod2man.

@scottchiefbaker scottchiefbaker changed the title Update pod2man to output HTML5 instead of XHTML Update pod2html to output HTML5 instead of XHTML Jul 20, 2020
@scottchiefbaker
Copy link
Contributor Author

@jkeenan oh good catch. It's definitely pod2html I typod.

@Grinnz Grinnz added ext/Pod-Html issues in the blead-upstream Pod-Html distribution type-utilities labels Jul 20, 2020
$ret = "$block\n</body>\n\n</html>";
} elsif ($mode eq 'html') {
$ret = "$block\n</body>\n\n</html>";
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read this twice (first when reviewing the entire changeset and again when reviewing this single commit) and twice I stared at this trying to understand what the difference is between the content strings until I realized they are exactly the same. (Both times I skipped the comment line.)

And it's true that it's well past midnight here, but I doubt having the same line of code twice with these conditions is a good idea.

	if ( $mode eq 'xhtml' || $mode eq 'html' ) {
		$ret = "$block\n</body>\n\n</html>";
	}

This is easier to read and allows the author to easily refactor this in the future, which I think is the intention.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just forward thinking on my part... Eventually the HTML5 and XHTML versions will probably be different so I broke them out to prepare for that. You are 100% right, that currently they're identical. If you feel very strongly about it I can merge them.

@@ -842,4 +834,53 @@ sub relativize_url {
return $rel_path;
}

sub get_header {
my $mode = shift() // "html";
my ($title, $csslink, $bodyid, $block) = @_;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very odd to me.

  1. You're sending the mode (html/xhtml) in the only call to this function, so it's pointless to check // "html".
  2. You're taking out the title, css link, body ID, and block immediately afterward, which is used by both modes.

I can only imagine one situation in which you would lack a mode but have correct values for the other variables - when you are sending undef to the function as the first argument. I can't see this happening.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're 100% right on this... this is an easy fix.

@@ -543,6 +530,7 @@ sub parse_command_line {
'recurse!' => \$opt_recurse,
'title=s' => \$opt_title,
'verbose!' => \$opt_verbose,
'xhtml' => \$opt_xhtml,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it more prudent to keep the current mode and turn on HTML 5 by having an --html5 mode.

My concern is what would break for various other non-HTML5 browsers. Before promoting making HTML 5 the default, I would look at lynx, elinks, et. al. to understand how they deal with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just installed and tested with lynx 2.8.9 and elinks 0.12-0.62 and both render the HTML5 how I would expect a text browser to do so. Both are 100% readable and happy.

@scottchiefbaker
Copy link
Contributor Author

I have done some fixes on this and am happy with the output. Please take a look and review.

@jkeenan
Copy link
Contributor

jkeenan commented Feb 4, 2021

This should address issue #17986.

This commit is best viewed with whitespace ignored. I normalized the line endings to not have trailing whitespace, and it makes the diff noisier than it really is.

For those playing along at home, I think this is done via adding ?w=1 to the URL.

https://github.com/Perl/perl5/pull/17987/files?w=1

@jkeenan
Copy link
Contributor

jkeenan commented Feb 4, 2021

Given that we're changing the output of pod2html, the expected output in all of the files in this library's test suite must change. I checked out this branch from the contributor's repository, configured and built perl, then ran this library's test suite. They all failed.

If the expected output in our test suite is failing, then so to is the output of any darkpan use of pod2html as a command-line utility. That suggests that whatever changes we settle on will have to go through a deprecation cycle before being released.

That in turn suggests that we have to decide on the merits of the change, for which the discussion is ongoing in #17986.

Thank you very much.
Jim Keenan

@Grinnz
Copy link
Contributor

Grinnz commented Feb 4, 2021

For this reason I would agree with Sawyer's comment here that an opt-in --html5 option would be better. #17987 (comment)

But I am not strongly attached to this opinion; the likelihood of darkpan code relying on pod2html's exact output is low.

@jkeenan jkeenan added the needs-work The pull request needs changes still label Feb 4, 2021
@jkeenan
Copy link
Contributor

jkeenan commented Dec 30, 2021

There has been no further discussion in this pull request since February of this year. The p.r. has had unresolved merge conflicts since July of this year.

My recommendation is that this p.r. be closed and that @scottchiefbaker (or anyone else who wants HTML5 output rather than XHTML) should explore this approach via a CPAN module. Such a CPAN module may wish to subclass ext/Pod-Html, especially since the sequence of method calls invoked by the Pod::Html::pod2html subroutine now documents the logical steps needed to convert POD to HTML. Such a CPAN module should also include a test suite that demonstrates the expected output of various arguments to that subroutine.

Unless someone objects I will close this p.r. around January 10.

Thank you very much.
Jim Keenan

@jkeenan jkeenan added the Closable? We might be able to close this ticket, but we need to check with the reporter label Dec 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review Closable? We might be able to close this ticket, but we need to check with the reporter ext/Pod-Html issues in the blead-upstream Pod-Html distribution hasConflicts needs-work The pull request needs changes still type-utilities
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants