Earlier quoted context omitted.
Have you misunderstood me? MathML does not work well even in Safari and Firefox, and that is why they are avoided.
I understood well what was said about Safari and Firefox. I may have misunderstood how well it works/doesn’t in Chrome. For right or wrong I understood that MathML didn’t work at all in Chrome. If there’s some support for a feature, even if it’s ropey, and if there’s no support for that feature in Chrome, then using that feature attacks Chrome. People will have to use other browsers in order to use that feature. They…
Chrome unlikely to support XPath 3.1
81–90 of 114 posts
Re: Chrome unlikely to support XPath 3.1
#82XML is undeniably a huge attack vector with a shrinking user base. I think that’s a very valid argument for not expanding its surface area.
Is it an attack vector? Can you elaborate further?
Re: Chrome unlikely to support XPath 3.1
#83Earlier quoted context omitted.
browsers are quite fast nowadays. they appear to be bloated mainly because of two reasons: 1) companies pulling in all sort of un-optimized content and making requests to a huge amount of external services, effectively slowing down the render of pages 2) a lot of developers developing stuff that should really be native code in html+js+css, which doesn't always perform that well and tends to slow down the whole browse…
No, the browser itself is bloated. For instance, the RPM for the Firefox I'm using right now is 100 megabytes, and that's an already compressed format. After installing, just one of the components (libxul.so, which has most of the executable code) is over 110 megabytes. Each new feature will only increase this size even more.
Re: Chrome unlikely to support XPath 3.1
#84Earlier quoted context omitted.
Oh, it's fine keeping the development tools open for local dev, but then it seems like developers (usually more junior) will get spooked when they open the application in a new tab, loading from the test server, and their changes appear to not have been built out, or only half built out. It causes some confusion, and I often need to remind others that if they are using Chrome, to please clear their cache. The other t…
I mean, to some degree you need to take advantage of build options that put out resources under unique paths, which I'm fairly certain is standard guidance by now.
Re: Chrome unlikely to support XPath 3.1
#85Earlier quoted context omitted.
I dont know, i think im biased against it because i have touched it (even of xslt is quite cool)
I changed my opinion of XML after I had to deal with yaml. Whoever thought it is a good idea for complex configs (kubernetes) was wrong
Re: Chrome unlikely to support XPath 3.1
#86Please just let XML die. Just because it existed doesn't mean it has to exist forever. Will there be pain points in getting rid of it for good? Yeah. But we'll be better off in the long run.
I don’t agree. Never touch a running system! I think you have no idea in how many software implementations XML plays an important role. Just because it’s not hot and fancy it does not mean it’s bad.
Re: Chrome unlikely to support XPath 3.1
#87Earlier quoted context omitted.
HTML and JavaScript. Works for PDF with PDF.js XML is no longer relevant to the modern web
PDFs don't use HTML. Standard PDFs are also not XML based. PDF.js ab- uses HTML to somehow render PDF. The HTML used by PDF.js is in no way a sane "human readable structured data" format. But a "browser compatible" ad-hoc representation for the underlying PDF representation. Lastly PDF are not formats for structured data, which is what XML is all about in the end. So I have no idea why you thing HTML+Js is a sane rep…
nah it mostly uses canvas and svg.
Re: Chrome unlikely to support XPath 3.1
#88Earlier quoted context omitted.
I changed my opinion of XML after I had to deal with yaml. Whoever thought it is a good idea for complex configs (kubernetes) was wrong
> Whoever thought it is a good idea for complex configs (kubernetes) was wrong Kinda agree, YAML is a mess wrt. many aspects. > I changed my opinion of XML after I had to deal with yaml. I still didn't change my opinion about XML, it is similar a mess wr. many aspects. For both there is a sane sub-set which isn't a mess and which looks reasonable fine. Sadly this subset has not necessary clear borders. So I guess a s…
Honestly if json had comments and allowed trailing commas it would be perfect.
Re: Chrome unlikely to support XPath 3.1
#89Earlier quoted context omitted.
> Whoever thought it is a good idea for complex configs (kubernetes) was wrong Kinda agree, YAML is a mess wrt. many aspects. > I changed my opinion of XML after I had to deal with yaml. I still didn't change my opinion about XML, it is similar a mess wr. many aspects. For both there is a sane sub-set which isn't a mess and which looks reasonable fine. Sadly this subset has not necessary clear borders. So I guess a s…
When we invented XML we did not have configuration files as a major use case- although the possibility of ubiquity had been hinted at in a speech by Michael Sperberg-McQueen earlier that year, comparing the potential of SGML to the infrastructure in tunnels beneath the city of Chicago. There's an XPath from 2016 (3.1) but it didn't have any significant input from browser people - so the primary audience represented w…
A super complex stack with questionable security properties and composes in a way that is the opposite of simple.
> people who don't think of themselves as programmers can do sane powerful & useful things - the languages are declarative;
Not sure how that distinguishes it from other markup languages. What are we comparing to that is imperative? TeX?
> XML documents can be in the problem domain - elements named after things they represent, not "div" and "span" for example
I mean i guess xml works better for data serialization than a soup of html. That is not exactly a high bar.
> you can write a custom grammar-based validation check that both gives some rudimentary QA and also helps to drive syntax-directed editors, hierarchical database schemas and so forth;
You can do that with any format you can parse into to an abstract syntax tree. I suppose xml is convinent compared to writing your own custom format in so much as you already have an off the shelf parser, but we're comparing different serialization formats, not having no serialization format.
> syntax errors are fatal, and there's some redundancy in close tags, which help catch errors that often can't be caught easily by checking the data (e.g. for metadata)
That's pretty standard for all data serialization formats. If instead of data serialization you are instead talking about mark-up languages, that's almost always considered a bad thing.
> For sure there are things we'd do differently with hindsight, but remember also that XML predates the success of JavaScript...
I think that's pretty debatable when it comes to javascript. Regardless though, hindsight may be 20:20, but there is still room to look at fundamental design decisions. People may quibble about aspects of css and js, but the fundamental design choices turned out to be pretty solid to this day. XML on the other hand comes off as a weird compromise that tries to do too many things, doesn't do any of them all that well, resulting in an ecosystem of over the top complexity.
Re: Chrome unlikely to support XPath 3.1
#90I mean some people working on Chrome tried to remove XSL support at some point: https://bugs.chromium.org/p/chromium/issues/detail?id=514995 which was already nuts, so they are clearly not interested in anything related to XML. XML is a fantastic tool, it's just that a whole generation of developers refused to even touch it and are biased against it. And since Chrome is now basically the web... wait til there is only…