> On Nov 3, 2017, at 6:42 AM, Richard Hipp <[email protected]> wrote:
>
> Option 1:
...
> And when new capabilities come out (such
> as CSP) it requires existing repositories to edit their header
> templates in order to insert the new information.
The current skin CSS diffing mechanism shows the way out of this trap. Merging
CSS changes on major upstream skin changes has been an occasional pain to me,
but it’s no worse than similar tasks like merging /etc contents on upgrading a
POSIX type OS.
> Option 2:
>
> Have Fossil take over complete control of all content HTML page
> continue up to and including <body>.
Let’s look at the list of elements that the user would no longer have control
over because they must appear in <head>, if this option is taken:
<title> (does anyone override this?)
<base> (probably only useful to Fossil itself)
<link> (more than just CSS; see below)
<meta> (lots of things)
The <script> and <style> elements may also appear in <head>, but they’re not
worth paying attention to in this context for two reasons. First, they cannot
contain inline content in this proposed strong CSP world. Second, both
elements can appear outside <head>, so we also don’t need to worry about
whether we care about the loss of <script src> or <style src> in <head>.
The loss of end-user control over <link> is the most serious problem I foresee,
because it means you cannot set:
<link rel="canonical" href="https://example.com/";>
This is a clue to search engines that if it found the current page via any
other path, such as Fossil’s https://example.com/wiki?name=Home link, that it
means the same thing as going to https://example.com/, so the two
apparently-different URLs should be treated as equivalent by a search engine.
This avoids diluting Google juice.
It’s about more than just page aliases. It’s also useful in cases where the
same site is served by multiple domain names. A good example is SQLite’s 3
mirror scheme. They’re currently diluting their Google juice because these
URLs are not marked as equivalent:
http://sqlite.org/
http://www.sqlite.org/
http://www2.sqlite.org/index.html
https://www3.sqlite.org/index.html
etc.
My public Fossils have the same problem, currently. They’re available via 4
different domain names, all equivalent. I don’t think I have the HTTP vs HTTPs
problem because I use a different method of redirecting HTTP to HTTPS than the
one built into Fossil, which clues search engines into the equivalency.
That only leaves <meta>.
Although <meta> has lots of uses, I’m not sure any of it matters for Fossil.
Search engines long since stopped seeing <meta> elements as valuable
information, after the SEO crowd started misusing them. I also can’t see that
overriding Fossil’s internal HTTP server via <meta http-equiv> or character set
via <meta charset> is useful.
> Option 3:
>
> Fossil automatically generates <html><head>...</head><body> and then
> appends whatever is in the "header" template, as with option 2.
> Except, if the header template already contains a <body> tag, then
> Fossil assumes that the admin knows what she is doing and lets the
> header template generate everything as it does now. Similarly with
> the footer, Fossil will automatically generating the closing
> </body></html> unless it sees that the footer script has already done
> so.
That works for me. It avoids all of my unease with Options 2. The only
problem is communicating the new behavior in an anti-RTFM world. It suffers by
being slightly magical, thus nonintuitive.
> Option 4:
>
> Behave as in option 1 or option 2, depending on a setting. The
> setting defaults to do legacy option 1 support. Then when an admin
> goes to update the header and footer scripts to the option 2 style,
> she also changes a setting to cause the <html><head>...</head><body>
> content to be prepended and the </body></html> content to appended.
I’m not seeing a reason to take on the complexity.
> The mere exercise of writing all this down as clarified my thinking
I’ve always found that to be the best reason for writing documentation, whether
user, reference, or design: to ensure the writer understands what it is he is
doing. :)
> "+1 Option 3”.
+1 Option 3.
_______________________________________________
fossil-dev mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
