It's pretty common to put classes on <body> tags, to use CSS to conditionally choose different renderings by simply changing the class of the body tag.
../Dave On 3 July 2018 at 00:23, mario <ma...@include-once.org> wrote: > 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 >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
