> On Nov 3, 2017, at 6:42 AM, Richard Hipp <d...@sqlite.org> 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 fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev