It's also not very wise in general to not read the final printed version of the contract before signing
139 karma · joined May 2, 2023
It's also not very wise in general to not read the final printed version of the contract before signing
Except ligatures are not limited to fi and ffi. They can be used to change appearance of any sequence of characters, including words.
> It's noticeable; a B consistently occurs everywhere there is an A, wherever that font is used.
I'm not talking about substituting a single letter. I'm talking about outright obfuscation of a entire texts.
> You can't perpetrate an easter egg whereby a certain A is replaced.
Quite the opposite, it is trivial to apply different fonts to different parts of text, so you can keep some parts of text normal, and some parts (like numbers and data) obfuscated. In HTML you may notice some abundance of <span>s, sure, but in PDF? Literally no way, unless you copy-paste everything and compare it.
And this is not a hypothetical scenario or a 'minor threat'. Russian government used precisely this technique to obfuscate data in their online voters turn-out reports: (source in Russian, not found it reported in English) https://habr.com/ru/news/578846/. Have they used more subtle scrambling of only digits and not also mixing letters: who knows how long it would take for anybody to notice. From a technical perspective it's not so different from contextual alternates - both require custom made fonts.
There are other ways to alter document presentation too. Especially in CSS, you can create pseudo-elements, not present in the original HTML, or hide parts of HTML, or use a media query which checks if the page is being printed or not!
> We could prepare a page where every glyph appears, and detect substitutions via OCR.
Why the extra step? Why not take the OCR of potentially compromised document and compare it with its raw content? It would detect every substitution, whether it's ligatures, alternates, media queries etc. Why not inspect the font file for defined alternates directly?
Unless this is about something different from what you mean, unfortunately, it's not the case, as stated in the article:
> Using base-select loses a number of features and behaviors:
> The <select> doesn't render outside the browser pane.
The most notable mental shift is that you create a Commit (git add && git commit) after you are done, whereas you create a Change (jj new) before starting working on it, and you don't need to explicitly save it after, you bookmark and push it, or start working on a new change.
Consequently, there is no distinction between working directory, index and the commit history. You only have one concept - Change, and you edit them however you wish, whether it's newly created change, or a very old one, or a merge, or whatever else
From my experience, you should be able to fit any git worklow in this model:
- Anything that requires creating commits is jj new, merge is also jj new.
- If you wish to only save part of the changes (like git add -p) you call jj split.
- git squash is jj squash
- amend is also squash
- rebase is automatic (jj edit or jj new --{after,before})
- git stash is obsolete (everything is saved anyway, just run jj new)
- etc.
And I do agree, that moving to better integration with native CSS is a step in the right direction, very curious about future of v4
[1]: https://adamwathan.me/css-utility-classes-and-separation-of-...
Exactly. It can serve HTML partials, or utilize `hx-select` attribute to extract required elements from a full page
> Is there a simple example of a static site using Htmx somewhere?
Not that I'm aware of unfortunately
Not affiliated with them in any way, but it's made with htmx and some JS for more complex features
As for "new class of web experiences", given that htmx explicitly aims to expand upon what is considered the Old Good approach, not sure if it can provide that
> it addresses a specific shortcoming of HTML: the on* attributes do not support arbitrary events
> it is much less featureful & useful than, for example, @Alpine_JS, but if you have very basic needs for event handling it can help avoid another dependency
Your solution, for example, will break if the target div already has content in it. It also won't work if we want to insert the content after or before the element, you need to somehow keep track of the element being triggered, so it will grow more complex.
And still, it won't work with custom events
> No need to bring up multiple examples. We just need one to show that htmx makes something simpler.
This approach is not productive. A single example could be easily dismissed on the ground that it's not enough to justify design decisions that htmx has. I wrote multiple examples and provided additional links specifically to show various use cases that htmx covers and to avoid playing ping-pong of tiny examples.
> This isn't one though.
You just picked one example, which also happened to be the simplest, and seemingly ignored everything else. I apologize, I don't know how to continue from here.
I separated those examples to different files: https://plnkr.co/edit/0TWYrtbMGP9UAzE4
Also, you may notice there is <template/> tag. It's just for the demo [1], it serves as a mock endpoint
Another big aspect of allowing to handle any event is integration with other JS libraries. See this basic example of interacting with Sortable JS [1]
Also, htmx has a response header called `HX-Trigger`[2] which lets server trigger custom events on the client and you can handle those events as well[3]. This is quite useful if you have interdependent data and you want to refresh regions on the page in response to user actions somewhere else (for which htmx allows multiple different patterns for different scenarios)[4]
[1]: https://htmx.org/examples/sortable/
[2]: https://htmx.org/headers/hx-trigger/
[3]: https://htmx.org/attributes/hx-trigger/#triggering-via-the-h...
You said it yourself:
> We all have finite time and it's great to learn something once and be able to use it multiple times.
We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions
https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
https://htmx.org/attributes/hx-trigger/ https://htmx.org/attributes/hx-sync/
Unless your new client is a hybrid/webview/electron application, it's a trap. APIs for web, for native and public API have different sets of constraints in terms of authentication, versioning, even features are probably gonna be different.
And it's not like building an API after you built web would be complicated. Unless you put your business logic right into controllers/handlers, making an API would be just making a new endpoint that calls to existing application services. It's not free, it may not be trivial, but like other comment said, if you can afford a new client, you probably can afford an API for it
The idea is easily extendable to any template engine, so you can keep your device response minimal while enjoying the simplicity of htmx. I will admit though, this approach gets funky much faster, than returning HTML fragments, so you probably shouldn't exclusively build your app with this client-side-templates
[1]: https://htmx.org/extensions/client-side-templates/ [2]: https://htmx.org/extensions/json-enc/
- https://htmx.org/essays/a-real-world-react-to-htmx-port/ by https://github.com/David-Guillot - a SaaS product migrated to htmx from React.
- https://zorro.management/ by https://twitter.com/Telroshan - a kanban project management tool. This one is particularly interesting IMO, it implements quite advanced UI with htmx and some custom JS.
The only thing that might cause trouble is non-standard (as in HTML standard) HTTP methods, which basically means any method other than GET and POST, I admit that. However, the fact that these methods are not supported even in HTML5 is a huge miss.