Fan of starship here. wanted to drop a few comments based on what I seen so far
Love the performance. Written in Rust and compiled to binary, it's _much_ faster than either python-based powerline, the bash-shell-based ohmybash and zshell-based ohmyzsh and spaceship.
You can use it for zsh, bash, sh, fish. but you can also use it for both MS Windows CMD and Powershell. I don't believe any other prompt tools can do all at the same time. And a single config file can control all of them on your system.
The default config is just that - a default. Too much information? you can change it. dont like icons? you can remove them.
At almost 100 modules to choose from, it's customization options are nearly limitless
Perhaps, but there ample room for improvement here.
The text simply say's it's cheaper, but the amount saved is not mentioned. This can be a big factor in changing people's behaviors. I may choose to shop at a local market for convenience, or fly a specific airline to get airline miles. In both cases, I know that I did not pay the absolute rock bottom price, but that the difference is small enough to not deter my loyalty.
Later in the article an example is given: "...Paddington to Canary Wharf would cost £6.70 if buying a paper ticket but £2.80 if using contactless payments" I am unsure how random that example is, but if typical, that is a massive 60% discount. Sharing that sort of precise information would certainly change habits of even the most loyal of paper customers.
It is of course far simpler (and cheaper) from a software design perspective to have the generic message, and perhaps it is all that could be accomplished in the timeframe allotted to the effort, and I understand that. But I do hope that more precise messaging is provided in the future so that we can revisit this discussion and review the results.
One minor problem is that the paper ticket is anytime, but the contactless fare had peak/off-peak fares…
So if you buy a paper ticket at 0925, you’ll pay 6.70 GBP. If you touch in and travel immediately you’ll pay 3.40 GBP (peak fare), but if you stop for a coffee first and the time ticks over past 0930 before you touch in, you’ll get the off-peak 2.80 GBP fare.
(I think there is actually a little grace time, and it may be when you complete the journey which matters, but the principle holds).
Concur is not "based" on SAP. Concur was acquired by SAP in 2014. The majority of it's existing codebase remains in place to this day. Even the newer more modern code base bits are reactJS based, not SAP based.
From the spec - The autocomplete attribute represents either:
a) autofill expectation mantle
b) autofill anchor mantle
If the input type is "hidden", then it is wearing the "autofill anchor mantle". IN ALL OTHER CASES (emphasis mine) it wears the "autofill expectation mantle"
And what are the rules on "autofill expectation mantle"?
"When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or autofill detail tokens
...
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; OR THAT THE DOCUMENT PROVIDES ITS OWN AUTOCOMPLETE MECHANISM AND DOES NOT WANT THE USER AGENT TO PROVIDE AUTOCOMPLETION VALUES. (emphasis mine)"
The "should" is in the spec's description of how to interpret "off": "When an element's autofill field name is 'off', the user agent should not remember the control's data, and should not offer past values to the user."
"The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."
In 4.10.18.7.2...
"When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.
NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."
@jeffk - Ok, I now understand where you are getting this interpretation.
I think this is a dangerous interpretation (and perhaps it requires altering the spec to say must). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 4.10.18.7.1.
My parent was saying Chrome was not compliant with the spec, but SHOULD directives are not mandatory and a User Agent may decide that it would be a worse experience for users to follow them.
Chrome is claiming that enough developers have marked fields as autocomplete=off in user-hostile ways that it shouldn't be respected, while many people here are making the case that conflicts with site-provided autocomplete and other issues push the other direction. That's how to have this discussion, not by pretending this SHOULD is a MUST.
(I don't work on Chrome and don't know any Google-internal anything about this)
Additional food for thought. Elsewhere, in 4.10.5.1.2 (Text (type=text))...
"If the element is mutable, its value SHOULD (emphasis mine) be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value."
If a browser offered a user a way to edit immutable fields, or blocked users from editing mutable fields, the discussion should be "is whatever reason they're doing this for strong enough to outweigh the presumption that following the web developer's request is the right thing to do". Not "the spec prohibits it, no matter how good your reason may be".
For example, you can use the browser's devtools to edit an immutable field, because "allowing someone to develop the site" is a strong enough reason.
It is a direct spec violation, and it is breaking all kinds of applications.
Look, I get that this capability is super useful on shopping sites, and I rely on it practically every day.
But, I also build enterprise applications, where Chrome simply would not ever understand or know what would be valid choice.
I do, though; I built it. Invoice Numbers / Pre-Validated Travel Dates & Locations / Pre-Validated Locations / Pre-Validated IssueID that are so esoteric, we have built custom autocomplete that provide additional relevant information / Pre-Validated Users where the number of valid "John Smith"s number in the 10s, and additional meta data must be provided to differentiate.
Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. The spec says this is autocomplete=off. Just do that.
There was a time when IE was the dominant browser, and happily did whatever they wanted to.
That was arguably better, because at least they acted predictably. Chrome has been continually altering how autocomplete is handled in the last 5 or 6 major releases
IE was far more dominant, and browsers actually had meaningful differences back then. Porting CSS written for IE to Firefox could easily take 50% of the initial implementation time, if not 100%. Today, it's not completely uncommon to have something developed on Chrome working in Firefox and Safari without any changes.
And the most significant problem with IE was obviously that it wasn't FOSS, and was only available for Windows. Neither applies to Chrome.
They are now a major user of chromium, and may contribute, but they do not have any say in what goes into chromium. That is still controlled by google employees. If said google employees do not like microsoft patches, they will reject the proposed changes, and microsoft can then at best push them into their own fork.
Google rejecting Microsoft changes has not yet been observed, it could happen.
Most people think that Google agenda could conflict with Microsoft agendas.
I have read a LOT of chromium issues.
I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them.
The truth is, except for maybe a few exceptions, chromium evolve through the decisions of engineers that want to create the best possible product.
They are not different to Firefox or edge engineers.
Thus they should collaborate pretty well and a Google and Microsoft team should not have more "conflicts" than between two Google internal teams.
As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
>I can tell you that the higher management at Google does not dictate chromium changes as they are too technical for them.
Tell that to the webRequest API that ablockers use.
>As you said for the exceptions, Microsoft can maintain a fork, it's still order of magnitude more economic and smart than to constantly duplicate work in a redundant browser (firefox)
Chrome is the redundant browser. Firefox was here first.
webRequest API
Well maybe it's an exception, but they have technical reasons mostly.
Webrequest v3 is not stable so wait and see.
Chrome is the redundant browser. Firefox was here first.
Well Chrome is based on khtml which is not that new but yeah Netscape navigator precede it.
Indeed it would have been better if chrome was based on gecko (FF) at the time.
But now Firefox can be thought of the redundant browser because of both marketshare and being technically an inferior product on most metrics.
If mozilla worked on improving chromium, think of the massive progress it would bring to the World!
Website would have no limits on what is possible to create. Everything would be fast, etc.
> webRequest API Well maybe it's an exception, but they have technical reasons mostly. Webrequest v3 is not stable so wait and see.
Bullshit. They decided they wanted this to fuck with adblockers, then found some "technical reasons" they could use as talking points, afterwards. Also, the reasons are apparently so "technical" and "necessary" that google said it would not apply the proposed crippling of webRequest to corporate deployments of Chrome. Corporate users apparently do not need privacy or performance. Go figure.
"B-but user privacy! Extensions can see request" - This is grand coming from google in the first place. Nonetheless, an easy way to solve this is to have special "webrequest" scripts which can apply rules etc, but cannot communicate out, so cannot exfiltrate data.
"B-but performance" - Wasn't a problem so far. If you're really concerned about those 10ms per request an adblocker might add, then either don't run one (and see how your "perf" behaves when all those nice ads load instead), or run one that uses the declarative stuff, which google can still implement additionally.
>If mozilla worked on improving chromium, think of the massive progress it would bring to the World! Website would have no limits on what is possible to create. Everything would be fast, etc.
By "massive progress" you mean outright monopoly on the internet technology for Google? That's not progress. I'm still mad at MS. Instead of taking google's sabotage (you cannot call it anything else really), they shouldn't just obeyed the new goverloads, but sued the living shit out of google. I bet they now a few good antitrust lawyers.
I seriously can't wrap my head around why anyone decided it would somehow be 'okay' to use googles web browser. Because unless you are a Pollyanna coolaid drinker you know where that's going to lead us.
Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.
Are you being deliberately obtuse? Choice of which browsers to develop for. You had to support IE6 back in the day. Now you have to support Chrome. When they do weird shit you can't say "well that browser is broken", you have to work around it.
Surely most people here are old enough to remember the days of IE6? It wasn't that long ago.
Curious - Is calling a building toy a "game" a regional dialect thing, like soda vs pop? I have never heard of Legos, K'nex, Tinkertoys, etc. referred to as "games" before.
Love the performance. Written in Rust and compiled to binary, it's _much_ faster than either python-based powerline, the bash-shell-based ohmybash and zshell-based ohmyzsh and spaceship.
You can use it for zsh, bash, sh, fish. but you can also use it for both MS Windows CMD and Powershell. I don't believe any other prompt tools can do all at the same time. And a single config file can control all of them on your system.
The default config is just that - a default. Too much information? you can change it. dont like icons? you can remove them.
At almost 100 modules to choose from, it's customization options are nearly limitless