Age | Commit message (Collapse) | Author | Files | Lines |
|
elm.min.js.gz shrunk by 9919 bytes. user.min.js.gz is now 9681 bytes.
Not a totally fair comparison and those few bytes are completely
irrelevant, but it at least shows that I'm not making things more bloated.
|
|
The idea behind the list icon CSS filters was that they could be
adjusted in themes, but (1) that never happened and (2) even with colors
embedded in the SVG they can still be adjusted with the same mechanism.
In that light, embedding the colors in the SVG is the cleaner solution.
|
|
Unique classes have lower chance of clashing with anything else.
Automatically generating the dimensions increases the size of the CSS
file a bit, but it simplifies maintenance. The only thing that's still
done manually is the selection between the .svg and .png image.
|
|
Couldn't get fragment identifiers to work satisfyingly, so ended up
going back to old-fashioned CSS background-position. Oh well.
|
|
|
|
Problems with the old implementation were that the setting wasn't an
intentional user action, so there were a LOT of preference writes that
were reverted a minute or so later. Wasting both server and visitor
time. For regular visitors, the localstorage-based approach also caused
a reflow if their preferences didn't match the default.
Downside of the new implementation is that regular visitors can't change
their preference at all anymore, this now requires an account. :/
|
|
But don't display them on the ulist itself yet, since that may be
confusing when the widget is added to that listing. Ugh, what a mess.
|
|
There's no way to list or aggregate the votes yet, and I'm not fully
sure the data model is what it should be. Hence testing.
|
|
I don't like the platforms listing in CSS much, after all, and I've
never been a big fan of the <abbr> hacks. Been experimenting with sprite
sheets and inline <svg><use..>, but for now I think the simplest
solution of just using <img> tags still seems the best.
Until I change my mind again and can't resist the allure of throwing all
icons in a single nicely compressed file.
|
|
Still kind of experimental, let's see how people react.
Icons contributed by eacil. Some are colored versions based on the SVG
icons contributed by xy2, some are vectorized versions of old icons.
These retain much of the legibility of the old png icons by virtue of
not being monochrome. At least for the dark skins. I may experiment
later to see if the monochrome icons may be a solution for light skins,
now that I have the infrastructure in place anyway. Not sure I really
want to maintain two icon sets, though.
I used scour to optimize the SVGs for size, but they're still rather
less efficient than the combined PNG sprites. Maybe I'll use an SVG
merge trick later, but that tends to be less widely supported among
browsers.
Closes #30.
|
|
https://vndb.org/t950.830
|
|
It's still missing a few mod features, will add those later.
|
|
|
|
|
|
Now with BBCode preview, interactive board search, client-side error
reporting and lots of new bugs.
This took me far too long, turns out it wasn't such a trivial rewrite.
|
|
I did not reimplement the 'poll_recast' and 'poll_preview' settings,
these actions are now always permitted.
Updated CSS a little bit to highlight the linked post and fix the double
border at the bottom.
The nice thing about the sql_visible_threads() function I wrote earlier
is that is can also be used for access control on a single thread. More
code re-use. \o/
|
|
Kind of backwards to use input elements to display a link when they're
backed by Javascript anyway. This also avoids the need to create a
unique id for each linkradio element.
|
|
I wasn't able to do this while the .maintabs used floats.
|
|
|
|
I'm really unhappy with the workarounds to deal with the global onClick
subscription doing the right thing, but I wasn't able to find a good
alternative.
|
|
|
|
Very much experimental. I'm not sure this is even the right model.
|
|
And I can't say the wikidata field is all that intuitive to edit. Need
to look at it later...
|
|
This is the first major editing form to be converted, so I'm expecting a
little breakage. A good chunk of this code has been copied from v3.
In terms of the UI there has been a small change: aliases that are still
referenced do not have the 'remove' link and instead have a flag that
shows that they are still referenced. This ought to be a bit friendlier
than throwing an error message after the user has submitted the form.
Some other things I'd like to improve in this form:
- BBCode preview
- Pasting in external links and letting the form figure out the Pixiv
ID, etc.
- Or perhaps even: Integrate AniDB/Wikidata search/autocompletion.
|
|
option
Elm has a bug where the 'selected' attribute is not properly propagated,
that's fixed by patching the generated JS.
Also moved Ffi.js one level up, as it's important that that file is
loaded before any Elm modules are initialized.
|
|
And add a small 'formField' function to shrink the Elm form generation
code a bit.
|
|
The insecure-password-change flow is now slightly more friendly. The
logout functionality has been hardened to use POST and require CSRF.
|
|
Most of this is copied from v3. I did improve on a few aspects:
- db_edit() and db_entry() use VNDB::Schema rather than dynamically
querying the DB. This has the minor advantage of a faster startup.
- The Elm code generator now writes to multiple files, this avoids
the namespace pollution seen in v3's Lib.Gen and makes the dependency
graph a bit more lean (i.e. faster incremental builds).
- The Elm code generator doesn't update the timestamp of files that
haven't been modified. This also speeds up incremental builds, the elm
compiler can now skip rebuilding unmodified files.
- The Elm API response generator code now uses plain functions rather
than code references and all possible responses are now defined in
Elm.pm. Turns out most API responses were used from more than a single
place, so it makes sense to have them centrally defined.
The doc page preview function is also much nicer; I'd like to apply this
to all BBCode textareas as well.
(Elm.pm itself is ugly as hell though. And we will prolly need some HTML
form generation functions in Elm to make that part less verbose)
|