Mon, 2 Jul 2018 17:20:17 -0600 Warren Young <>:

> Under what conditions would you have two different <body> tags in a
> single document differing only by class, and thus need a CSS selector
> to differentiate them?

Of course you wouldn't want two <body> tags.
But that's exactly the bug I ran into:

<!DOCTYPE html>
<base href="http://localhost:8080/timeline"; />
<meta http-equiv="Content-Security-Policy"  content="default-src 'self'
data: 'unsafe-inline'" /> <title>Plugin Meta Data: Timeline</title>
<link rel="alternate" type="application/rss+xml" title="RSS Feed"
href="/timeline.rss" /> <link rel="stylesheet"
href="/style.css?id=6f242840" type="text/css"  media="screen" /> </head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <base href="http://localhost:8080/timeline"; />
  <title>Plugin Meta Data: Timeline</title>
  <link rel="stylesheet" href="/style.css?id=6f242840" type="text/css">
  <link rel="stylesheet"
type="text/css" /> <link rel="stylesheet"
type="text/css" />
  <!--script type="text/javascript"
<body class="wy-body-for-nav" role="document">

If you use a skin header with `<body and=attributes>`, current trunk
will prepend a default <head> section and second <body> tag:

> /*
> ** Default HTML page header text through <body>.  If the
> repository-specific ** header template lacks a <body> tag, then all
> of the following is ** prepended.
> */

It should check for <body%>, not just a fixed byte sequence.


> > I see the value in the draft feature, but it's
> > also a bit confusing still (while working on broken skins at
> > least.)  
> While I agree that the new skin editor is considerably more
> complicated to use than the pre-2.5 method, I also don’t see how to
> make it simpler without losing functionality we gained in that
> release.

TBH, I haven't really given it much more thought.

It's clearly more practical to have secondary skins to work on,
without harming the active/default template. And being able to
grant additional edit permissions there is a nifty feature. As
is the built-in help and step-by-step guide.

It just got in the way for the aforementioned issue.

> > - draftN… just treated as saved skins?  
> I don’t see why that couldn’t be done in principle.
> The main practical problem is that skins can be named in a way that
> would require ugly URL escaping to be specified in place of the
> current draftN bit:

If the PATH_URI detection can only only recognize `draftN` prefixes,
than having all of them available wouldn't make sense. With the ugly
percent escaping anyway.

> There is a side-benefit of this change: if someone has a public
> Fossil instance and one of the end users thinks the default skin is
> ugly, he can change it by selecting the name of a skin he likes
> better in the URL.  Currently, you can only change the skin this way
> in a local clone which you’re running “fossil ui” on.

Rather than extending the internal path dispatcher, supporting a
plain/per-user cookie migth make sense. -- OTOH, this might already
be feature creep..

> I’m not seeing the value of that change.  The current mechanism is:
> 1. Select the skin/draft to edit.
> 2. Click the CSS/Header/Footer/Details edit links.
> Are you proposing to replace this with a grid, with skin names down
> the left edge and 4 edit buttons per row to the right of each skin
> name?  That does not sound like a simplification to me.

It's sort of what came to mind. But indeed, that would probably just
make it more convoluted.

One simplification in the whole skin conundrum could be merging
css+header+footer+settings editing into one page (4x textarea)
Then it might be presentable in a table/grid scheme:

 check   test
 boxes   links
   ↓       ↓
  [ ]  Skin name    [Edit]
  [x]  Backup2      [Edit]
  [ ]  Draft1       [Edit]
  [Activate]  [Use as Draft]  [Publish]  [Delete]

With the buttons just acting on the current selection.

 * Could be fewer action buttons though.
 * [Rename] or [Publish] better part of the css+head+foot editing
 * The `Authenticate` option should really be part of the `Display
   Details` settings blob, btw.
 * It would likely suffice if the template name doubles as test link
   (don't see the need for five test links).

> If you have something different in mind, a graphical mockup or
> wireframe drawing might help get your point across.

I'm gonna give this a bit more thought. There's quite a lot of
backend code for the template management already. Not really sure
if any of this would simplify code or editing workflows.

fossil-users mailing list

Reply via email to