So user privacy is definitely implicated.
So user privacy is definitely implicated.
For those making anything at a production scale where you need wcag compliance however, I'd avoid this and leverage a proper semantic token layer. Semantic tokens will help both accelerate your dev cycle, and they'll help guarantee proper contrast ratios in a way that looks visually better than just switching your foreground layer to black or white. The great thing about a semantic token layer is they're extremely easy to theme, which means you get light/dark theming for very little additional cost. You can also create separate WCAG2 / APCA accessible themes, should your brand color be one of the ones that WCAG2 has issues with - will get you compliance while still providing a better visual contrast option.
This is kind of my niche domain specialty - I run the variables/tokens stream at Figma, and I've worked on the dark mode implentation for both Figma and Atlassian. Happy to answer any questions about tokens/themes/accessible color.
This exact type of functionality has caused a major project a work on to use CSS in JS (for relative colors and contrast colors.
I’m glad to see this type of thing coming around the corner and look forward to it being widely available in a couple years.
<ul>
<li><a href="about.html" target="display">about</a></li>
<li><a href="contact.html" target="display">contact</a></li>
</ul>
<iframe src="about.html" name="display"></iframe>
The important part is that the target iframe must have a `name` attribute (not identified by `id`.) I guess, this is a legacy of framesets & frames.(Of course, this has all the issues of framesets, as in deep linking, accessibility, etc.)
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.
IMO the thing that would be really nice is if control flow like `for` was actually the same as using an iterator. This would really help in Rust too where handling errors inside iterator callbacks is a right pain.
I've seen a few languages try this but it seems to not be very popular. I think it can get a bit confusing how control flow keywords like `return` and `break` work if you turn `if` into syntactic sugar for a function call taking a closure etc.
In PHP you loop through an iterator with the foreach control structure.
In JavaScript you use for of.
In rust it’s for in.
What am I missing?
Im pretty sure it’s not just me getting old. Movies and series from the 1990s or early 2000s don’t have this problem. It’s like they are streaming the cinema mix rather than the home video mix.
Alternatively you could get a 3.1 audio setup and just boost the heck out of your center channel.
I also use PHPStorm for web dev work and we use MS DevOps at work and that extension is unstable, causes IDE errors for me and I will not use MS products just for this one irksome bug. I prefer PHPStorm for my work, because working with PHP in VS Code has never been a great experience for me. I just want my tools to work, I fight with code, I don't want to fight with my tools as well.
> 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.
Well that’s disappointing.
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
So people work around the little paper cuts, while still hitting the traps from time to time as they forget them.
> generate YAML
I've a hard time finding a situation where I'd want to do that. Usually YAML is chosen for human readability, but here we're already in a higher level language first. JSON sounds a more appropriate target most of the time ?
Whenever I have to fight something like this it always makes me question the goodness of the pattern to begin with. Stacking multiple modals/popovers/tooltips can’t be a great UX (or accessibility) pattern, can it? I find at least half the time that I’m fighting the browsers it’s because I’m trying to do something suboptimal