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
Conversation
Is your subject line for the Issue correct? I would think the update would be for |
pod2man
to output HTML5 instead of XHTMLpod2html
to output HTML5 instead of XHTML
@jkeenan oh good catch. It's definitely |
Adds a --xhtml to use output XHTML instead
Adds a --xhtml to use output XHTML instead
d0f0ca4
to
c17e423
Compare
ext/Pod-Html/lib/Pod/Html.pm
Outdated
$ret = "$block\n</body>\n\n</html>"; | ||
} elsif ($mode eq 'html') { | ||
$ret = "$block\n</body>\n\n</html>"; | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
ext/Pod-Html/lib/Pod/Html.pm
Outdated
@@ -842,4 +834,53 @@ sub relativize_url { | |||
return $rel_path; | |||
} | |||
|
|||
sub get_header { | |||
my $mode = shift() // "html"; | |||
my ($title, $csslink, $bodyid, $block) = @_; |
There was a problem hiding this comment.
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.
- You're sending the mode (
html
/xhtml
) in the only call to this function, so it's pointless to check// "html"
. - 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.
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
I have done some fixes on this and am happy with the output. Please take a look and review. |
For those playing along at home, I think this is done via adding |
Given that we're changing the output of If the expected output in our test suite is failing, then so to is the output of any darkpan use of 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. |
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. |
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 Unless someone objects I will close this p.r. around January 10. Thank you very much. |
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.