bullman

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.

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.

disappointed this is not called "hotdog / not hotdog"

Learn more here: https://github.com/jeffhandley/strickland

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."

https://html.spec.whatwg.org/multipage/input.html

So, according to this spec, the UA is allowed to make an input field type=text non-editable if it so chooses.

Would you argue that this is another place where Chrome would be allowed to act in a manner differently than expected, because "SHOULD" was used?

So then the crux of the conflict:

In 4.10.18.7.1...

"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.

Where is this supposed "should"?

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)"

Per: https://html.spec.whatwg.org/multipage/form-control-infrastr...

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

This brick:

NzRyg7XKhGLLe6BXzQn7p1wMA9PG1ouPG2a6DO1ey5gmlqqAT6YDwdTAjOXZGlZc6k8bYqlm2Q5DuHmtFj4oJWemEFmi9MhJ6h1Q

I think there others too

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.