Regarding the <menu> element, which the OP mentions their confusion about as:
> I was initially surprised that it survived to HTML 5 (while <menuitem> didn’t) because modern browsers treat it as essentially a <ul>. Researching further on Wikipedia I read: "MENU existed in HTML Tags, and was standardized in HTML 2.0; deprecated in HTML 4.0 Transitional; invalid in HTML 4.0 Strict; then redefined in HTML5, but removed in HTML 5.2," and now I don’t know what to think.
HTML 5.2 was retired by W3C in 2021 in favour of the WhatWG HTML Living Standard, which (unlike HTML 5.2) never deprecated <menu>, and has been redefined as representing "a toolbar consisting of its contents, in the form of an unordered list of items (represented by li elements), each of which represents a command that the user can perform or activate.".
Wikipedia's list of elements seems to be out of date here — along with a lot of the Wikipedia information on HTML versions — as the <menu> element is still alive. Given its history of being repeatedly deprecated, and the fact that event recently browsers were confused by exactly what semantics to assign to <menu>, you are probably nearly always better off using <ul> with an appropriate ARIA role attribute (toolbar, menu, or menubar).
Really cool site! After playing with it for a while, could the CSS gradient for MIX could be changed to use the same number of color stops as there are steps rather than just using the start and end, to better match the chosen interpolation mode? I had a great gradient in LAB space, but the CSS version interpolates through ugly greys in RGB.
> Ideally, the games themselves would have some sort of API, or some other way to either communicate what’s happening in the game so I can map colors to it
A number of games implement Mumble Link (https://wiki.mumble.info/wiki/Link) which provides a memory-mapped file that includes positional data used to provide directional sound by voice-comms software (so when a teammate speaks you hear their voice as if you were both in your relevant locations in the shared virtual space). Some games also expose other data through this including health/mana/ammo levels which could be used to control lighting based on game state.
Although this might be much, much harder because you'd have to trick each SDK into thinking it's talking to the devices it expects. A good example of this is a nice hack that takes Logitech LED commands and sends them to a Corsair keyboard instead - http://forum.corsair.com/v3/showthread.php?t=140755
This is one place where some common standards / APIs would have really helped. Instead, the community is left to do all the work.
That's another great idea. I'm looking for a Razer Chroma API, not much luck yet, but their site[1] seems to have some info. Of course, they're going to make it much easier for you to tell their keyboard what the color should be than to read that color...
There's been quite a few people exploring logitech gaming keyboards with LCD (G19 etc), adding pidgin plugins, games widgits etc. Maybe you can get enough from github to figure out what you need?
Or there's Roccat's power grid which interfaces games to a phone app. No idea how open or investigated that is though.
Aha! That's very interesting, thank you. I had no idea this was a thing, but it looks like I can use it for some interactions. I'll explore further, thanks again.
I was also in this room, merged in from powerlanguage's side into Notch's group. The group ended up convincing about 40-50 members to vote to Stay, and when the vote passed it created a private subreddit for the group with random members as admins (including Notch). This was before auto-vote scripts and bots became common.
The subreddit is currently coming up with a theme for itself (based on part of the name that was automatically generated for us), and has seen users sharing spare copies of games and introducing themselves.
Unfortunately /u/powerlanguage chose to grow on without us.
I ended up in a group of four, of whom two were initially inactive. One of them eventually started chatting (apparently the desktop notifications hadn't worked) and we voted 3/4 to grow again. The next batch of people to join us started slinging slurs around, at which point I closed the tab.
I'll have to have another go at this tomorrow, if it's still up.
I am seeing blurry text on every tooltip as it animates in, not just the one on the download button. I assume it is related to ClearType rendering the text on non-pixel locations.
To see where this might lead, consider the UK, where this is already the case. The Equality Act 2012 [1] (which itself is a replacement for the Disabilities Discrimination Act which also applied to websites) requires:
A person (a “service-provider”) concerned with the provision of a service to the public or a section of the public (for payment or not) must not discriminate against a person requiring the service by not providing the person with the service.
It applies to websites (Airline BMI Baby was sued by the National Institute for the Blind for failure to meet the as-then Disabilities Discrimination Act).
The typical paraphrasing I hear from developers is that it requires an organisation (but not necessarily the developer) to make "every reasonable effort to comply", for which there is a baseline of appropriate colour contrast and reviewing WCAG validation.
It does mean that developers for UK-based services are less disposed to Javascript-heavy applications/components and video content (because of the requirement for ARIA and transcripts/CC respectively).
Mark Hurrell has blogged some of his testing on Helvetica font stacks (including Neue) at http://blog.mhurrell.co.uk/post/2946358183/updating-the-helv... which is worth a read. Current recommendation is to specify sans-serif but with additional specifications for Linux:
I have always been uneasy about the fact that Urchin/Google Analytics 'campaign tags', when copied and distributed via other services, do not continue to represent the original campaign. For example, for the following campaign URL includes three additional pieces of information:
The moment that you store that URL in other service, a number of those tags become incorrect anyway (it is not an email anymore), and the stats you will get from it will be tainted. Campaign tags are useful, but this approach by pinboard may end up in tracking being more accurate (certainly from in terms of tracking campaign media/terms/content), at the cost of removing the campaign name.
There is also little difference between this and a URL such as http://example.com/Free-Summer-Tickets/June-2011-Newsletter?... being set up to serve the original content other than at least with the campaign tags you've got a single canonical URL using the more correct query parameter mechanism.
Yes I think this is exactly what bothers me about it too. The fact that I use bookmarks and send links to others makes the information slightly skewed.
I also think, maybe I'm missing something. Maybe it's actually decent information to have. For instance, if you send a link with source=newsletter to somebody, it still is the newsletter that brought both of you to the site. You may not have visited otherwise. And your friend, probably even less so.
I don't know. I still don't like seeing it. It really does defeat the purpose of making your site have pretty links.
> The moment that you store that URL in other service, a number of those tags become incorrect anyway (it is not an email anymore), and the stats you will get from it will be tainted.
It sounds like you're probably misunderstanding the actual use case involved.
If you're a business, paying for traffic, you want to know ROI. If you spend X dollars and get Y visitors which make you Z dollars, you want Z > X, and you want to know what the relationship between the three values are, to know if spending more would be worthwhile. You don't actually care if the human being who clicked the link was currently in their email, rss, or anything else. You wan to know "spending dollars this way resulted in this profit". You want to identify the source, in your dollars, of your income.
> I was initially surprised that it survived to HTML 5 (while <menuitem> didn’t) because modern browsers treat it as essentially a <ul>. Researching further on Wikipedia I read: "MENU existed in HTML Tags, and was standardized in HTML 2.0; deprecated in HTML 4.0 Transitional; invalid in HTML 4.0 Strict; then redefined in HTML5, but removed in HTML 5.2," and now I don’t know what to think.
HTML 5.2 was retired by W3C in 2021 in favour of the WhatWG HTML Living Standard, which (unlike HTML 5.2) never deprecated <menu>, and has been redefined as representing "a toolbar consisting of its contents, in the form of an unordered list of items (represented by li elements), each of which represents a command that the user can perform or activate.".
Wikipedia's list of elements seems to be out of date here — along with a lot of the Wikipedia information on HTML versions — as the <menu> element is still alive. Given its history of being repeatedly deprecated, and the fact that event recently browsers were confused by exactly what semantics to assign to <menu>, you are probably nearly always better off using <ul> with an appropriate ARIA role attribute (toolbar, menu, or menubar).