crdx
commented
11 years ago I think that a better design is to have the default CSS not be exposed to the user [...] Instead, the user would create their own rules from scratch, which would be applied on top of the default.
I vote for this. This is how I expected it to be done when I first installed MDH and was surprised it wasn't.
For this latest update, knowing I had customised the CSS but unable to remember in exactly what way, I saved my current version and then got default, then diffed the two and figured out what I had changed.
That worked out pretty well for me, but that's because I (like you I'm guessing) deal with diffs on a daily basis. If you attempt a three-way merge there's going to be some situations where user intervention is going to be required to handle conflicts, and it's possible the user has no idea what on earth this whole "merge" thing means (even if they made some CSS changes). I assume while a lot of MDH's users are developers, that's not necessarily exclusively your target user base, and you want it to remain accessible to everyone.
dverbru
pradyunsg
I recently realized that the way CSS is customized in MDH is pretty poorly designed. (When I say "CSS", I'm mostly going to be referring to the "Primary Styling CSS", but the discussion will also largely apply to the syntax highlighting CSS.)
The way it is, which isn't good
The main problem is that it's nearly impossible for me to update the default CSS for users (which is important: there have been bug fixes and significant cosmetic changes in the CSS). When a user first installs MDH, the default gets set in the user's options, and then it's basically locked in forever, regardless of changes to the default. In theory, the user's options-CSS could be checksummed against the previous default and updated if it hasn't been changed. But if the user has modified it at all... it becomes a really painful merge effort.
The way it should be
I think that a better design is to have the default CSS not be exposed to the user, and not get set directly into their options. Instead, the user would create their own rules from scratch, which would be applied on top of the default. (So, where now you immediately see a "Primary Styling CSS" box full of rules, instead you'd see a blank slate... or some helpful hints.)
That way, if the default CSS changes, it would just silently change underneath the user's customizations. Which leads to...
Caveat 1: Changing the default could break the user's customizations. Because of CSS precedence, it's possible to create an earlier rule that overrides a later one. So I could introduce an "improvement" that inadvertently, silently, mysteriously trounces a user's customization. Relatedly, I could modify or remove styles that the user depends upon to make their customizations look right. This is unfortunate, but I think it's acceptable -- the default CSS doesn't change so often or drastically as to impact many (if any) users in this way.
An alternative
Basically, the "painful merge effort" mentioned above.
There are JavaScript libraries (Synchotron, google-diff-match-patch, others?) that do three-way merging. So we could merge the user's customized previous-default CSS with the current default.
This is unpleasant for a few of reasons:
The plan
First of all, feedback is welcome.
This feels high-ish priority. It's terribly user-unfriendly to make them click the reset button every now and then (and if they've customized the CSS... good luck).
After I put out 2.8.1 (which includes a CSS bug fix!) I'll probably start on this.