These days new uses are mostly for public interfaces (business-to-business services like orders/invoices), services in regulated markets (energy, telco, medical) and eGovernment (tax statements and other financial reporting eg based on ISO 20022), as opposed to internal microservices. Other than that, it's kind of a "boomer" thing in the sense that it was the wire format to choose around 2000 when most businesses went online, and it just prevailed. Same thing with EDIFACT which was established earlier and still rules logistics.
The actual point of using a markup language for service payloads that aren't intended to be read by humans in the SOAP times was just that you can simply style it up (using CSS or XSLT back then) without having to go all the way to bring a full frontend toolkit/JavaScript into the stack along with insular know-how for merely viewing messages when your primary backend language was eg. Java.
We can do better than "known for decades, on a layman's level" folklore and the answer actually isn't as straightforward ([1]). Recently there's even been discussion (by a Brit scientist I believe but I have no reference) on skin cancer vs more serious forms of cancer, and also about skin pigmentation playing a role here.
HTML was invented as an SGML vocabulary, and SGML and thus also XML has entities/text macros you can use to reference shared documents or fragments such as shared headers, footers, and site nav, among other things.
Not one of the downvotes, but: as far as I'm aware, there was never any syntax which could be used for HTML transclusion in the browser. There may have been SGML or XML syntaxes proposed for it, but none of them were actually implemented in this context.
You can use entities to create static sites in advance, or by including support in the browser. sgmljs can do both, and simply using shared headers/footers for static site generation from markdown and other SGML partials is explained in [1].
SP/OpenSP and older SGML tools were most certainly available and used to assemble HTML docs from command line apps in the 1990s for complex websites with lots of content such as software documentation. The editor of the HyTime spec with its strong focus on adapting and transforming to multimedia and web was working with a training/education company. W3C's long-term validator service ran off SP.
XSLT was implemented in every browser like 25 years ago and has the ability to include other document templates/fragments client-side. It's exactly the functionality everyone always says is missing.
I do. It's great that the UI is stagnated, but unfortunately the UX is too. Things like bluetooth not being integrated with the DE, and various details that we take for granted not working correctly
Face ID is severely lacking compared to MS Hello, simple as. It's at best 50:50 hit/miss compared to Hello which logs me in always. Granted, that figure doesn't include false positives, but the difference is substantial and makes Apple's implementation look really lame, to the point I'd like to see it removed.
TFA's URL reads why-css-bad.html pointing at its originally intended title lol.
> [your browser rephrasing your text into smaller words] might be slowly becoming possible but is clearly outside the bounds of what CSS would do
When it comes to CSS, nothing seems out of scope. It's gaining conditionals (if) as we speak.
In hindsight, I wish Pavel had used something other than Z3/SMTLib for his CSS formal semantics, such as a Prolog-derived CLP language. Not that Z3 is bad, but the hope was that CSS spec authors could pick up and test/maintain the ruleset with new CSS features. Rather than unapologetically continue to add crap to CSS unhingedly. Or alternatively, expose layout to JS and then provide a common JS implementation for layout computation, as the Houdini project was proposing. I mean, that's what JS is for right?
Is anyone really using bazel outside Google in any meaningful capacity? There used to be a number of really popular and widely used projects such as closure compiler, gwt/j2cl, guava and other Java libs, and supposedly lots of golang stuff (not to speak of k8s where people seem to be satisfied it's a black box) that are dying behind bazel walls.
I lost a month to Bazel a few years ago. The documentation had so many holes and what was there was either out of date or wildly inaccurate. You could not produce an Angular build using the tutorials as written. Everything was wrong. I'm sure Bazel great if you have a team of people to write bespoke libraries on top of it for each of your targets. I ended up using turbo for frontend and uv workspaces on the backend.
The actual point of using a markup language for service payloads that aren't intended to be read by humans in the SOAP times was just that you can simply style it up (using CSS or XSLT back then) without having to go all the way to bring a full frontend toolkit/JavaScript into the stack along with insular know-how for merely viewing messages when your primary backend language was eg. Java.
reply