On Jul 2, 2018, at 8:11 AM, mario <ma...@include-once.org> wrote:
>
> This misses anything but plain <body> tags in the header
> ↓
> if( sqlite3_strlike("%<body>%", zHeader, 0)!=0 ){
> Th_Render(zDfltHeader);
> }
>
> It might rather be %<body% or %<body%>%, so any style attributes
> like <body class="PageyMcPageface"> get recognized still.
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?
I suspect this is just a bad example, but then I ask myself, if I’m going to
apply CSS styles to a tag, wouldn’t I just put it into the CSS file, which I
can already modify without changing Fossil?
What’s the real motivation here?
> 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.
This feature set solves a few real problems faced by drh during the 2.5
development sequence in support of the many UI improvements he made while
actively soliciting feedback on those changes. In order to get that feedback,
he had to point people to a running instance, so rather than take the expense
and complication of setting up a public demo server, drh created this feature
set so he could demonstrate proposed skin changes using the fossil-scm.org
instance to get that feedback.
This feature set adds the following abilities:
1. Lets normal site visitors A/B compare proposed changes by visiting URLs
differing only in the skin draft’s name.
2. The Fossil admin user can now invite others to edit the skin.
3. Edits can be made to drafts, so you can test on a production server without
breaking it for uninterested users.
The prior way skin editing worked, only the admin user could switch and edit
skins.
I don’t think you’re going to see any changes to this mechanism unless your
proposal can achieve the same ends.
> - 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
A secondary problem is that it appears that Fossil’s current URL parser can’t
quite cope with that once decoded, based on the 404 error pages it generates.
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.
> - edit header/footer/css buttons for each draft/skin
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.
If you have something different in mind, a graphical mockup or wireframe
drawing might help get your point across.
> - and [test] urls for each available backup/save/draft
We already have that: it’s Step 5 on the setup_skin page. The test URL list
changes whenever you change the draft name in Step 1.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
