Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
One of the rules on HN I vehemently disagree with. These tangential annoyances often coincide with genuine accessibility issues, and should be called out when seen.
I agree with you, to be called out when seen if applicable, although maybe it would be useful to be able to separate which comments are about such thing than not.
Fortunately, if there is such a top-level comment, any other comments can be replies to that and so you do not need to fill up the top-level comments with such kind of complaints, I think.
If it were reliably contained to one thread I don't think there would even need to be a rule, yeah. I often see it where a bunch of top-level comments are spelling out the same 2 or 3 issues (some in a mean-spirited way), and though I care deeply about software accessibility, that is itself a usability issue for HN.
Sorry about that, I did actually forget about that, but in my defense I offered something constructive to save others the trouble of having to cook up that console snippet themselves
... and the icons are a mixture of the two and the name is a link and the "BY-NC-SA 4.0" is an internal link, not to be confused with the CC icon which goes to the license. The good thing about standards: so many to choose from!
I'll try to bear your "new site, new visual iconography" preferences in mind when I build out my site and decide that Captialized links are offsite links, MiXeDcaSe are dynamically generated ones, and all text except hyperlinks will be blue underlines
This person's site is clearly packed full of innovative idea; I don't understand why CSS tomfoolery needs to be one of them in order to make it stand out
No self expression "needs" to be there. We can criticize it's effectiveness and accessibility, but let's not insist that people's individual blog sites conform to a uniform standard. I'd like the web to be weirder and more experimental. I'd also like users to be empowered to overwrite these decisions when it impacts their accessibility, or even if it's just not to their taste. We can have both.
Yes, the convention is not at all obvious. I also thought it was a link-free page and closed it the first time thinking there wasn't really much to show.
It doesn't once you know the secret code (i.e. a user manual in the form of your comment). I read the page with interest but I thought those were just like a stylistic choice, like a stand-in for specifics (which makes sense for a hyperlink in retrospect).
That is true, but unfortunately it is not implemented very well for other purposes; most of the stuff relating to accessibility tends to be made for blind users. While it is possible to help blind users, good accessibility would be able to help everyone, whether you can see perfectly fine or not.
"ARIA view" with a user specified CSS and using a combination of HTML and ARIA roles to decide how to display, can be helpful, perhaps. (This would be true for form fields too; some web pages implement their own, but sometimes specify by ARIA codes, what they represent; you can use that to replace them by the standard widgets instead of their specialized ones.)
The links are accessible to everything which can determine an <a> exists, uniquely defined with a visual indicator that doesn't require color, and show before you hover if it is internal or external.
Requiring a link to be underlined doesn't seem productive from an accessibility perspective to me. I did some research on a11y and didn't see anything in the audit checklists that this violates [0], could you explain what the precise issue is?
The link styling system used on the wiki complies with all web accessibility standards: it clearly and consistently shows a link without using color as the sole determining factor. An underling is not required (whether you think it should be or not, though feel free to get involved, join a working group, and lobby for the change to your hearts content... though I think it will be an uphill battle for you). Accessibility standards are about helping those with disabilities. What you are experiencing is a difference of opinion about _usability_. I personally do not experience the same usability issues, but to each their own on that one. Accessibility and usability are two very different things and should not be conflated.
> Accessibility and usability are two very different things and should not be conflated.
Nope. They are the same. It's a taxonomy of convenience.
I do not care what W3C says about this.
Example: If you have something with say clean typefaces it may be considered more usable unless the person has low vision or dyslexia then it's accessibility. The labels are easily swappable and there's tons of learning and attention disabilities people have (most people are probably not cognitively perfect).
What if you add an elevator to a building with a bunch of stairs. That's accessibility for the handicapped but also usability for others and thus we've swapped in the opposite direction.
You can take everything labeled usability and relabel it accessibility with a slightly different narrative and the reverse is true also.
The distinction therefore, in this context, is illusory. It's not an actual material difference here, just a fiction.
In scholarly research sure it's not the same. But in the material world without the clinical precision of scholarship, they are in practice always intertwined.
And this is fine, I don't care. A taxonomy of convenience is still a convenient taxonomy. Let's not kid ourselves however...
If you dont care about the standards, which governments use to define how accessibility works and who it applies to for legal purposes, then you essentially want to make up your own rules, policies, and ideas. Which is fine, mostly. However, it doesn't really give you solid ground to stand on when making an argument about other people's work. The fact is that according to the recognized "experts" on the subject (I'm using recognized here because again, governments use these standards and they have legal merit) there is nothing wrong with these links. There is, however, something wrong with conflating accessibility and usability. They are different. One applies to protected classes. The other has to do with everyone, but is in no way protected. There are legal ramifications to one. With the other, you are maybe a jerk for doing things against usability, but if it is equally bad for everyone, it often is not an accessibility issue. Accessibility is about leveling a palying field, usability is an opinion based thing regarding how a random person might interact with a website and usually relates to design decisions, not programatic experiences.
> Example: If you have something with say clean typefaces it may be considered more usable unless the person has low vision or dyslexia then it's accessibility. The labels are easily swappable and there's tons of learning and attention disabilities people have (most people are probably not cognitively perfect).
If it's equally a problem for everyone then it's not an accessibility problem.
(And don't think for a second that any design avoids causing problems.)
The link styling is inconsistent with basically every other web page; underlines haven't been "everywhere" since the late 1990s (for better or worse), but distinguishing links has usually been done via the use of color, maybe some other border effect.
The style chosen by this particular web page comes across not as hyperlinks, but as a weird choice to randomly remove words and phrases from the main sentence matter, rendering them more difficult to read and comprehend, and worse, leaving the reader unaware this this choice actually denoted a link.
Using color alone to distinguish links is explicitly an accessibility violation. Underlines are not a requirement. I certainly agree that the link system here is atypical. It just isnt an accessibility violation.
Really cool initiative, and with a really pleasant community.
The author lives on a boat, using only electricity generated with solar panels.
Xcode didn't work out that well under those circumstances, which was one of the driving forces to create uxn. Another is the desire to make programs that can run pretty much anywhere, and will remain possible to run in the future. Similar to how you can run NES roms on lots of devices.
Also, "Devine Lu Linvega" is just the name of someone you'd follow in battle, even if it's a battle that will lead you to your certain death. Just saying.
because the original poster was selling people Devine based on how cool a moniker they had.
It's a stupid gripe, but imagine that you're an enlisted soldier who is working their way into getting into the squadron lead by 'Tommy the Terrible' -- a simple example but i'm a simple guy, and it relates to battle analogy earlier.
Once you arrive you realize that Tommy the Terrible was just given his first command, he was promoted to the position due to being the member of a powerful family, and he commanded his unders to only refer to him as 'Tommy the Terrible', rather than gaining the title through the respect of his triumphs and leadership ability.
In other words, a name given by oneself has less impact in most societies than one achieved through achievement or familial ties.
Anyway, that whole differentiation is ridiculous within this context, I just thought it was necessary to explain.
Devine has earned the cool moniker, self-administered or not.
> Once you arrive you realize that Tommy the Terrible was just given his first command, he was promoted to the position due to being the member of a powerful family, and he commanded his unders to only refer to him as 'Tommy the Terrible', rather than gaining the title through the respect of his triumphs and leadership ability.
This is such an unfit simile. Your birth name is not "earned" either. You think Elon Musk's kid earned the name X Æ A-Xii (or deserved depending on your perspective)?
I had done a few writing uxn programs, and figured out some tricks with programming with this.
I think that there are a few problems with it, one of which is the delete/append ports of the file device, which I had proposed a change, to allow seeking and a few other things. (Deleting files in a uxn code is probably not that important anyways. Uxn32 allows deleting directories too, although since there is no way to create directories using uxn, deleting directories seems worthless.)
I also made some enhancements to the assembler. Some of these do not match what other people had done, so due to this sometimes there are two ways of doing the same thing. It was before the symbol file output, so instead it has its own symbol file format (although it might be possible to use the official assembler to convert the symbol file). If necessary, I might need to add switches to control some options, e.g. different versions of the uxn assembly language (since sometimes changes will break some old programs, even if the target instruction set has not changed), symbol file format, etc.
I have not implemented any optimizations in the assembler, since I think that the writer can make the optimization by themself (or, possibly, can have a high-level programming language capable of uxn, but I do not have such a thing).
I dislike the proposed metadata formats. For one thing, I think that it is unnecessary for a device port to be allocated for this purpose. Also, specifying capabilities would be useful, I think; at least to me, it seems more useful than including icons.
1. Make a header similar to Game Boy. The first four bytes are jump past the header (which might also be used to define the length of the header, in case of being extended in future), and then there is some sort of logo or code to identify the presence of the header, and then the data of the header.
2. Put metadata in a separate file, to avoid using up memory in the program file.
3. Put all of the files together in a Hamster archive file. Lump names starting with a underscore can be used for the special use, e.g. "_default.rom" for the program code and "_metadata" for the metadata. In this case an extra step is required to run the program if the emulator does not support it, but I wrote a program in uxn which is capable of doing this, therefore it can be used with any implementation of uxn.
So, any of these should be able to work with any emulator, even existing implementations which do not implement metadata.
I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box.
What we could do is just not expect the #xxxx #f0 DEO2 bytes as magic number, so you can just ";meta POP2" at the start. That wouldn't "use" anything, I mean, in its current state, it doesn't really occupy a port, vectors can always be overwritten, even if some day the #f0 device does become something, we could immediately write the same vector with another address in the reset vector.
> I'd like for the metadata to exist in memory tho, in almost every app, I read that metadata within the rom itself, I don't want to be fetching that external file each time I need to display the about box.
Then, you could use my first idea, of the first four bytes skipping past the header which starts with a code to identify the header (such as ASCII text "UXN!META", or whatever else might be agreed on); this is similar to the way that the Game Boy header is working.
> so you can just ";meta POP2" at the start
Yes, that would also work, if it is agreed that this convention is used for that purpose.
Presumably the poster would have posted about the overall platform instead of the processor, if that was what they found interesting and wanted to discuss.
> I have this implementation of the uxn virtual machine that has 32 instructions, how can we add a few more instrucions do implement memory pagination? (code here)
To implement memory pagination, we can add a few instructions to the existing set of 32 instructions in the uxn virtual machine. These instructions could include:
1. PAGE_IN - This instruction would be used to load a specific page of memory from the underlying storage device into the virtual machine's RAM.
2. PAGE_OUT - This instruction would be used to save a specific page of memory from the virtual machine's RAM to the underlying storage device.
3. SET_PAGE - This instruction would be used to set the current page of memory that is being accessed by the virtual machine.
4. GET_PAGE - This instruction would be used to retrieve the current page of memory that is being accessed by the virtual machine.
These instructions could be implemented as follows:
#define PAGE_IN(x) { u->page = (x); u->dev[0x0f] = 1; }
#define PAGE_OUT(x) { u->dev[0x0f] = 1; }
#define SET_PAGE(x) { u->page = (x); }
#define GET_PAGE(x) { x = u->page; }
int
uxn_eval(Uxn *u, Uint16 pc)
{
...
switch(instr & 0x1f) {
...
case 0x1a: /* PAGE_IN */ PEEK(a, pc) PAGE_IN(a) pc += 1 + bs; break;
case 0x1b: /* PAGE_OUT */ PEEK(a, pc) PAGE_OUT(a) pc += 1 + bs; break;
case 0x1c: /* SET_PAGE */ PEEK(a, pc) SET_PAGE(a) pc += 1 + bs; break;
case 0x1d: /* GET_PAGE */ GET_PAGE(a) PUSH(src, a) break;
...
}
...
Not only these opcodes are already assigned, this would be a very much overkill implementation of this functionality by wasting opcode space, whereas a simple device port would do the trick. It's telling that everyone's first reaction to Uxn is to write a compiler for it, or adding extra memory - it's more about finding fun projects to do that fits within such a restricted space.
Very interesting website and projects there, will have to poke around more. Is great to see someone interested in programming and tech also interested in reducing their impact on our global ecosystem and a vegan too!
I've never actually thought about low power/tech constrained programming, I feel like this could be something that would fire me up again in the tech industry, so sick of the more more faster faster approach.
Why is this different/better than emulating the PIC micro controller instruction set (or something like that), except that no hardware actually supports it? As I recall they had about 32 instructions. Not bashing, just asking.
I gave a talk about the various options I considered in the beginning, it's linked up on top of this thread by someone. In short, I didn't really care to have to design a CPU, I just wanted to drive a framebuffer. The PIC was a pretty poor target for what I had in mind, but I did nearly settle for the J1 which is a gorgeous design, the 4kb program limit was pretty tight, and it ended up being quite slow when emulated on the NDS.
I wrote a couple of notes that might interest you:
Neat idea. I'm imagining something like an FPGA or MPPA [1], where you program an interconnect (pipes) between dozens of available cores (processes), which can be configured to do one of a few hardcoded types of stream processing (commands) with a few flexible options (switches).
I made one of these about 18 years ago. It was a stack-based machine which meant I could get the instruction set under 32. I wrote a compiler for a little Forth-like language targeting its instruction set. I wanted to turn it into a fantasy console, but never wired up the graphical, sound, and input bits for that.
I'm pretty sure you could fit a blockchain into 64kb of memory too. Not sure why you'd want to do such a thing though except for amusement (the reason a lot of us do anything at all).