[Issue 15470] Unnecessary markup in ddoc's html generation

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Dec 23 08:27:04 PST 2015


https://issues.dlang.org/show_bug.cgi?id=15470

--- Comment #9 from Charles Smith <csmith.ku2013 at gmail.com> ---
(In reply to Andrei Alexandrescu from comment #5)
> We can do some of these with relative ease bot some others are likely to be
> difficult. In particular,
> 
> <td><span class="d_inlinecode donthyphenate
> notranslate">float.nan</span></td>
> 
> is an artifact of how generation occurs, first the code font is expanded
> then the table tag is expanded. Merging those two is nontrivial with what we
> have.

This is what I figured, I figured I'd point it out just the same. Unfortunately
these kind of things can make designing new templates a bit chaotic, since you
end up with oddball things like:

div#search-box, span#search-query, span#search-dropdown, span#search-submit
{
    border: 0.1em none #aaa;
}

I should've explicitly listed this as a concern.

> All of these issues in aggregate, including whitespace, would add to some
> inefficiency. I think it may be unmeasurable or difficult to measure, and at
> best add only to a couple percent. Certainly at this point "all of these
> things can account for slower page loads, which can impact page ranking in
> search engines" is pure speculation.

Fair enough, it was a weak argument, and as Adam pointed out, gzipping makes
this not even that. The only concern I was thinking of when pointing this out
was more for search engine page ranking, which favors compact compressed sites,
but I have no idea to what degree.

Nonconforming and deprecated html however is also present, and that is perhaps
a larger issue. I don't suspect browsers to just stop what they're doing
already that fixes the mistakes, so it might just be good to know for the
future.

--


More information about the Digitalmars-d-bugs mailing list