MSRP of an Apple TV device is $129. The iPhone's market share in the U.S. is already over 60%.
But neither matters because the Apple TV app is available on basically everything and can be used to buy movies.
But if you use the app you’re only streaming from Apple servers. That Apple server copy can be revoked at any time. And 60% is not 100%, my point stands you need an expensive device just to purchase and watch it. Probably multiple expensive devices if you want to actually watch it on your TV. When can I download my movie onto my Linux laptop and play it through an HDMI cable?
But you can run Steam on Linux. You don't have to worry about whether they're going to discontinue the cheap Steam Box you were relying on. And they have built up credibility from decades of not pulling the rug, in a way that Apple hasn't and probably can't.
Apple has been running the iTunes Store without "pulling the rug" for about as many years as Steam has existed.
Hell, they ditched DRM on music in that time period too and will sell you lossless ALAC as well as MP4 audio. (They obviously weren't able to talk Hollywood into that.) Steam is DRM that ensures the capability to pull rugs.
> Apple has been running the iTunes Store without "pulling the rug" for about as many years as Steam has existed.
Maybe. It's not been a very prominent line of business for them, and even then I can recall a couple of significant dramas over that time - didn't they merge two different kinds of libraries and cause confusion? The unremovable U2 album is also a cause for concern, not because an extra album is bad but because it implies they see the contents of your library as up to them rather than you. Most of all, they went out of their way to break music being sold by Real for iPods, which hardly suggests a company committed to interoperability and open platforms.
> Hell, they ditched DRM on music in that time period too and will sell you lossless ALAC as well as MP4 audio. (They obviously weren't able to talk Hollywood into that.) Steam is DRM that ensures the capability to pull rugs.
Not "obvious" at all, and precisely the point at issue. I'm happy to buy music from Apple, but movies require another level of trust that they haven't reached yet. I will grudgingly, cautiously buy games from Steam when they're not available on itch/GoG, and maybe that's unfair, but Apple have never sent me the message that they want or care about me (a non-Apple hardware user) as a customer of their movies.
The number of people doing it is irrelevant because the larger point was being able to download the movie on any platform. Steam on Linux is just a good example of supporting almost all platforms to distribute media.
You can download a copy of the installers and game files on steam. Steam allows you to install on any hard drive or device that runs Steam. Streaming apps download and store data in drm encrypted formats and by and large do not allow you to keep copies of that data for your own use.
You're moving goalposts and ignoring what I wrote. An Apple TV box is not expensive and you can use even cheaper streaming devices to buy and watch instead.
No you’re ignoring the criteria for why someone would want Steam for Movies. It’s not for the pleasant thought that they can stream movies from Apple and download it when they want through specific hardware. People back up their games from Steam and actually do own a copy of the installer and game files. That is a huge difference.
The DRM in Steam is not one of ownership. It’s one of needing a Steam account to buy and access those installer and game files.
“You can just stream your movies from proprietary device through apple tv app” isnt Steam for Movies in the spirit of the idea. What you have described is no different than having a streaming only subscription where you dont own the files and can’t access a copy of it offline. However you are correct that if you don’t care then you probably never wanted to own a copy of the files in the first place.
That's not what your original message was about and please don't invent quotes that are not what I wrote or anything like what I wrote. You wrote:
> The iTunes movie store is not friendly outside of the Apple ecosystem. Making the entire idea not really affordable since you need a expensive electronic device to utilize it sanely. Might as well find another way to get to it at that point.
I pointed out that buying a movie from Apple does not require an expensive device and does not require buying any hardware from the Apple ecosystem.
You ignored the facts and kept going on about having to buy expensive Apple hardware, which it isn't and you don't.
You moved the goalposts by requiring not only that purchases not require hardware that's expensive or from Apple, you added that it must not be revocable or streamed and must work on Linux.
I am not advocating for the iTunes store or any other source for buying media, I lost interest in owning TV or movies long ago, I was just providing factual information about what doing so requires.
No I’m not arguing about the specifics of the Apple ecosystem, you are. And you’re still ignoring what a Steam for Movies would be. That’s the conversation, not “iTunes Movie store can stream movies”.
And I am providing factual information on what a Steam for movies is.
Also when I write things in “quotes”, does not mean someone is quoting you or inventing things you said. Quotes have many uses and contexts. Perhaps if you cannot stay on topic or focus on the criteria of what is being discussed and dont understand how quotes work, this forum is not for you.
Steam for Movies and how iTunes store does not fit that description is exactly what my original message was about. Please stop pretending otherwise.
> When can I download my movie onto my Linux laptop and play it through an HDMI cable?
Probably because the Linux market is too small to support an iTunes for Linux.
By my understanding, the Linux market prefers free, open source, community effort. So essentially the real question is: why aren't you making movies yourself and sharing them free with your Linux peers?
Valve made the Linux market work by bloody persistence, because Gabe Newell saw the Microsoft Store as a threat to turn Windows into a walled garden (which would have hurt Steam a lot). It's not the Linux user base as such which attracted Valve.
But it's really beside the point, since supporting games on an OS is a hell of a lot harder than supporting video. You're right that movie stores have no excuse - except the control argument, working the other way than it did for Valve.
I actually have made movies and they are all available to download online for free. Not the gotcha you think. And also totally unrelated to the idea of Steam for Movies.
> So essentially the real question is: why aren't you making movies yourself and sharing them free with your Linux peers?
This is always the dumbest style of argument.
P1: Healthcare sucks!
P2: Oh yeah? Why aren't you a doctor?
Be serious. It's perfectly fine to criticize things and the answer is extremely rarely change your life and become a domain expert in something else to meet some kind of "oh yeah, be the solution" nonsense by somebody that often themselves refuses to get off the couch for anything meaningful.
There is no pair for the enterprise users signing in with their company's SSO or those using Passkey.
I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.
If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist.
Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts.
It's very low on my list of concerns though, usually there's much worse problems when I pentest.
They have defined what exactly needs to be done to be compliant, it's basically "meet WCAG 2.1 Level AA" with some additions. WCAG has already been the de facto standard for decades.
I assume you have not read Directive 2016/2102 and/or EN 301 549, because your approach is nice and so very, very, very suable.
The issue is not accessibility itself. I'm all for making things simpler. The issue is that the EU framework combines broad principles, partial technical references, vague proportionality requirements, and evolving judicial interpretation. In practice, that means the exact compliance boundary is often only defined by a judge during litigation, and with the website operator funding the clarification process through lawyer and court fees.
That is precisely the kind of legal environment that creates serial-litigation ecosystems like the ADA lawsuit industry in the US.
With systems becoming increasingly more complex, testing all potential code paths increases effort exponentially. With content being user-generated, not necessarily system-generated, you now technically need an editorial watchdog position that greenlights every change (if only to prevent Sally from Sales to post a meme in copy without a proper alt text, or worse, an infographic, without a wall of text describing the infographic in great detail).
And for the attacker, they only need to find one case of violation - while you need to be correct 100% of the time.
The only two ways to migitate such issues are
1. do not offer the service in Europe at all and actively prevent EUians from acessing any part of them - which becomes increasingly attractive (disclaimer: I am an EUian, unfortunately),
2. implement defensive overcompliance far beyond practical usability requirements, or
3. accept ongoing legal uncertainty and budget for it accordingly.
Unfortunately, "just build reasonable software and trust common sense" is not a stable legal strategy anymore.
None of that legal complexity has anything to do with putting "aria-labels on absolutely everything."
> And for the attacker, they only need to find one case of violation - while you need to be correct 100% of the time.
I don't know how European regulators work but even in the litigious U.S., this is not true, at least not in the courts. However, for small businesses, which are more likely to be targeted by the trolls, the cost of proceeding far enough to get a suit dismissed is burdensome. And in the EU, I thought individuals couldn't bring cases to a judge, they have to complain to a regulatory body that can decide whether proceeding is warranted or not.
> implement defensive overcompliance far beyond practical usability requirements
This is like complaining about having fewer grams of rat turd in your flour than legally mandated; "Oh no, we made our product too good!"
In practice, building "reasonable software" has never included making it work for people with disabilities, despite WCAG and the web standards themselves existing for decades.
> And in the EU, I thought individuals couldn't bring cases to a judge, they have to complain to a regulatory body that can decide whether proceeding is warranted or not.
EU regulations get made into member state laws, and these vary massively in who can sue through what way.
In Germany, for example, a common enforcement vector is the "Abmahnung" under unfair competition law. In theory, if a regulation imposes costs on compliant businesses, competitors should not gain an advantage by ignoring it.
The problem is that this has historically created an ecosystem of professional cease-and-desist mills. A competitor (or an organisation acting on their behalf) identifies a violation, sends a lawyer's letter, demands reimbursement of legal costs, and requests a cease-and-desist declaration with contractual penalties for future violations.
Whether the underlying issue is accessibility, consumer protection, labeling requirements, privacy notices, or something else is almost secondary. Once compliance becomes sufficiently complex, the enforcement mechanism itself becomes a business model. The cynic in me can't help but notice that our parliaments are made up disproportionately by lawyers.
That is why many businesses are worried less about accessibility itself and more about legal uncertainty around accessibility requirements. The concern is not "making websites accessible is bad."
The concern is that compliance costs are barely predictable, while litigation risk arising from ambiguous compliance boundaries is not.
I don't know what accessibility tools you're thinking of. If you mean assistive technology software like screen readers and voice control, yes, too often they fail to do what they should even when web standards are followed but at least as often the fault is with the web browsers (assuming the page code is all technically correct).
I'm not aware of any accessibility reasons to not simply use a <dialog> element for dialogs. For it to be a modal dialog, it must be opened using the `.showModal()` method or the invoker command `command="show-modal"`.
The hack of needing to implement roving tabindex techniques is not due to the failings of accessibility tools but because of web standards have not yet provided an alternative (adding the `focusgroup` attribute to the HTML standard is in the works).
lol, you should actually read the HTML spec, there are good explanations of all the elements. The whole point of defining semantics is that elements have meaning independent of their default appearance (or any appearance).
> I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.
Everything looks really simple when you ignore vast amounts of the subject and nuance.
Your rules don't mention keyboard or focus behavior, the only mention of either is the association between <label> and its <input>. <output> does have functionality, it's an HTML-native ARIA live region (that can be associated with a <label>).
Well, it took about a decade for web standards to become a real thing and a lot longer for Web Platform Tests to come to be. Still, while there are lots of tests for DOM construction and visual rendering, testing construction of the accessibility tree is lacking (also keyboard interaction testing).
And that's just for browsers, there's no shared spec for the operating system accessibility APIs the browsers' accessibility tree has to be translated into or how screen readers (and other assistive technologies) will use the OS's APIs.
Eh, it's fine, elements should be defined for what they mean, not what they look like. The explanation and distinctions made between <b> and other elements (<i>, <em>, <strong>) make sense.
The suggested (not obligatory) user agent styling for <b> is `font-weight: bolder` an agent or authors could use lots of different things to bring attention to what the element contains and treat it differently from <strong>.
The entire purpose of an element like <b> is what it looks like. If we're being inclusive, then the entire purpose of an element like <b> is what it looks like, how it sounds, how it feels in Braille, and so on. Nothing more. It does not map to some abstract concept.
It should be defined as: When rendered on a visual display device supporting bold font, it makes the text bold. The specific behavior is not guaranteed and may vary based on the user-agent. For example, screen readers will pronounce the text with emphasis.
The entire purpose of <b> was what it looked like. They changed its definition to not be about what it looked like but why an author might make it look that way, i.e. to bring attention to it. The representation flows from the motivation, there's no need to embed a look in the definition.
In practice today, that's fine. Typically authors have a hard time differentiating what "emphasis," "importance," and "bring attention to" mean to them. Therefore, nothing conveys a distinction by default.
So then what's the point of making this distinction? I would like to see surveys of how many people actually author content in forms that differentiate between b and strong.
Because the elements already exist. When the elements were invented and defined, CSS didn't exist and authors had to use elements to make presentational changes.
When HTML5 was defined, CSS was well established and it was an opportunity to update element descriptions to get rid of specific presentational qualities.
There are lots of elements, if you don't find some of them useful, don't use them. Other people may find uses for the distinctions; even if they use distinctive styling for them all, they may need to document why they're used, not just for all the authors but for the audience as well; clearly we can't expect developers to know what all the elements are for so that's doubly true for the audience.
Personally I think we should declare that b and strong mean the same thing, and that i and em mean the same thing. As the other commenter points out, there's no real semantic difference between "bring attention to" and "emphasize".
What, you don't know what's the difference between "emphasis" and "bringing attention to"? Shame on you, shame on you: you're unworthy to write HTML.
The difference, of course, is that one is a Latin word, and the other is an English phrase with the same meaning. But they're different words, so different tags. It's all completely rational and logical, and if you don't see the logic and/or reason, well: you're unworthy to write HTML. See Figure 1.
P.S. I love this ancient "see figure 1" meme. It's originated in the early 80s, and still as relevant as ever, and probably will be forever.
Please stop submitting SPR's. This is our system. We designed
it, we built it, and we use it more than you do. If there are some
features you think might be missing, if the system isn't as effective
as you think it could be, TOUGH! Give it back, we don't need you.
See figure 1.
---------------------------
! - !
! { } !
! | | !
! | | !
! .-.! !.-. !
! .-! ! ! !.-. !
! ! ! ! ; !
! \ ; !
! \ ; !
! ! : !
! ! | !
! | | !
! !
---------------------------
Figure 1.
Some phrases have stuck with me, like “mandatory defaults“, “they told their users to see figure 1 a long time ago” and the flippant “sometimes we blow it though”.
There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style <select> options. Keyboard navigation is free as long as you follow the rules about which elements are focusable.
You shouldn't have to care about screen readers the same as you shouldn't have to care which browser someone uses but you always have to care about people; people who can't see or hear what you create, people who can operate a keyboard (or keyboard-equivalent) but not a mouse or touchscreen, people who can use a touchscreen but not a physical keyboard, etc.
https://support.apple.com/en-us/119890
reply