Mon, 2 Jul 2018 17:20:17 -0600 Warren Young <war...@etr-usa.com>: > 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> <html> <head> <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> <body> <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" href="https://media.readthedocs.org/css/sphinx_rtd_theme.css"; type="text/css" /> <link rel="stylesheet" href="https://media.readthedocs.org/css/readthedocs-doc-embed.css"; type="text/css" /> <!--script type="text/javascript" src="https://sphinx-rtd-theme.readthedocs.io/en/latest/_static/readthedocs-data.js";></script--> </head> <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: > > https://fossil.example.com/Blitz%2C%20No%20Logo%20(built-in)/home 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) however. 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 page. * 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
