You have to give an iframe a specific height in pixels. There is no “make this iframe the height its content wants to be (like normal HTML).
This leads to two options:
- your page has nested vertical scroll bars (awful UX)
- you have to write JavaScript inside and outside the frame to constantly measure and communicate how tall the frame wants to be.
I guess, the best you could do is emulating a frameset layout with a fixed navigation and a display frame for the actual content. (By setting the overflow to `hidden` you can get rid of the outer scrollbars.)
> I have been pressured multiple times by Brian Ingerson (one of the authors of the YAML specification) to remove this paragraph, despite him acknowledging that the actual incompatibilities exist. As I was personally bitten by this "JSON is YAML" lie, I refused and said I will continue to educate people about these issues, so others do not run into the same problem again and again. After this, Brian called me a (quote)complete and worthless idiot(unquote).
> In my opinion, instead of pressuring and insulting people who actually clarify issues with YAML and the wrong statements of some of its proponents, I would kindly suggest reading the JSON spec (which is not that difficult or long) and finally make YAML compatible to it, and educating users about the changes, instead of spreading lies about the real compatibility for many years and trying to silence people who point out that it isn't true.
> Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even though the incompatibilities have been documented (and are known to Brian) for many years and the spec makes explicit claims that YAML is a superset of JSON. It would be so easy to fix, but apparently, bullying people and corrupting userdata is so much easier.
Are there no cases where well-formed JSON could be subject to the problems covered in the article, when parsed by a compliant YAML parser? I'm asking because I know nothing about YAML and not much more about JSON.
Not that I know. JSON requires strings to be quoted which is basically the problem here. Of course it’s not a great human writable configuration format (no comments being a huge problem).
I’m just pointing out that it should be very simple to swap a YAML file for a JSON file in any system that accepts YAML
You can make text selectable, but it still won’t behave at all like normal text. Selection word boundary things won’t match the local platform behaviour, touch behaviour cannot possibly work properly, things like context menus won’t work properly, and more.
The only way you can get the proper behaviour for these things on the web is to use actual DOM text. Some parts of it could in theory be made possible, but I doubt that anything meaningful will ever change—it’s too antithetical to the nature of the web.
"Proper behavior"... You've defined this term as the precise behavior of the technology that Flutter aims to supplant.
Indeed, Flutter will never do everything "properly". But that's not its selling point. It doesn't need to, as long as the number of users reached from a multi-platform release outweighs the users lost because they were offended by a missing native feature. (Assuming you're not some massive company developing a parallel app for each platform)
Fair. If that's the deciding factor on whether you use a computer program, that's your prerogative. I assume, then, that every app on your phone allows you to select every bit of text in it?
Cool. Was hoping to discuss the different expectations we have for a program obtained through a web browser than one obtained through an app store, but I guess downvoting is easier. ¯\_(ツ)_/¯
This is the nice if your only consumption of the frontend is first party.
Alternatively you could go the openAPI route and declare your API as a spec with types for a client to consume and the endpoint to return. This works cross-language and gives you docs first. (Start from the docs, convert that to types, then implement).
I just wish YAML wasn’t so unwieldy for that, especially given the overall complexity of the spec.
I also thing that the tooling hasn’t kept the same pace as it has with graphql, where it’s easy to document your schema and the inspector makes it super easy to play with.
You can write OpenAPI in JSON, which can help a bit with encompassing the complex and frankly fractured ecosystem of OpenAPI.
I have found that the tooling tends to have the problem of not knowing how to catch edge cases like webhooks, websockets, complex auth and additional logic beyond just an HTTP request. Many tools add layers of configuration and extension to work around these, but i feel it misses the mark.
I'm building Borea.dev to solve this pain by keeping the source of truth in your OpenAPI doc and allowing for custom code implementations. We support Python rn, are building out generators for multiple other languages and we're open source :P hope it helps
You have to give an iframe a specific height in pixels. There is no “make this iframe the height its content wants to be (like normal HTML).
This leads to two options:
- your page has nested vertical scroll bars (awful UX) - you have to write JavaScript inside and outside the frame to constantly measure and communicate how tall the frame wants to be.
Or you could just not use frames.