11 ms·
Chrome unlikely to support XPath 3.1
- deleted 6y ago[deleted]
- crazypython 6y agoSafari tends to be slow to implement features, but they rarely outright reject implementing a feature. Google Chrome hasn't implemented MathML yet, even though Firefox and Safari have: https://caniuse.com/mathml https://caniuse.com/mathml
- netheril96 6y agoThe MathML support in Firefox and Safari are barely usable. Even if my target audience all browsed on Firefox and Safari, I'd avoid MathML.
- the_other 6y agoDon’t let perfect be the enemy of good. Use MathML, put up noticea that your content only works in Safari and Firefox. These are all attacks against Google. FIGHT!
- netheril96 6y agoHave you misunderstood me? MathML does not work well even in Safari and Firefox, and that is why they are avoided.
- coldtea 6y ago>MathML does not work well even in Safari and Firefox Parent understood that, that's why they said "Don’t let perfect be the enemy of good". They mean "It might not work too well, but it works well enough to use".
- the_other 6y agoI 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 might then continue using that browser.
- barefootliam 6y agoMathML is being added to WebKit; an implementation offered for Safari was rejected years ago.
- drran 6y agoIt looks quite capable: https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test$samples/MathML_Torture_Test?revision=1506691 https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje... https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Project/Extras$samples/Mixing_with_other_markups?revision=385073 https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje... https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Project/Extras$samples/MathML_Tooltip?revision=385073 https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje...
- repiret 6y agoI followed your first link on Safari. Some things look fine. Some things are ugly, which is too bad but tolerable. If it was just that, I might consider MathML. But some things are rendered in a way that changes their meaning, and that’s totally unacceptable.
- lern_too_spel 6y agoMathML support in Blink is under active development. https://bugs.chromium.org/p/chromium/issues/detail?id=6606 https://bugs.chromium.org/p/chromium/issues/detail?id=6606
- deleted 6y ago[deleted]
- chromakode 6y agoSafari has been holding the web back for years on features that make the web competitive with Apple's app ecosystem. I don't believe the distinction of "rejecting" vs being slow has merit. https://caniuse.com/push-api https://caniuse.com/push-api https://caniuse.com/mediasource https://caniuse.com/mediasource
- runroader 6y agoSafari vs. iOS Safari is a distinction that needs to be made and people need to keep in mind. Apple's a lot more likely to allow stuff in desktop that it won't even consider for iOS. I mean your own link for media source has it being fully supported since 2014 in desktop Safari.
- esprehn 6y agoApple has refused to implement a large number of features, at least as many as Google. They're usually more quiet about it though unless it's part of marketing related to privacy. All the browsers take strong architecture and ecosystem positions.
- samtheprogram 6y agoActually, they do refuse sometimes, not that I’m against it, but it’s inaccurate to say they don’t. https://www.zdnet.com/article/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/ https://www.zdnet.com/article/apple-declined-to-implement-16...
- acqq 6y agoThere “due to privacy concerns” could still be a real motivation.
- anuila 6y agoI think that’s misleading since Safari’s development is not generally discussed outside the occasional WebKit blog post and the rare Safari developer on Twitter who may or may not rightfully ignore any questions/arguments. A lot of features are implemented late and incorrectly. I think that the first Safari version that supported PWAs was so broken that many had to manually exclude the browser in their support detection code.
- dmitriid 6y agoSearch for rniwa on GitHub, he's one of the core developers, and is active in all discussions (including meeting notes that are often published in GitHub issues).
- donatj 6y agoXML 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.
- richx 6y agoIs it an attack vector? Can you elaborate further?
- barefootliam 6y agoNo. XML libraries increase the attack _surface_, but XML itself is passive. There was a famous "billion laughs" attack, but JavaScript was also vulnerable to this, as is any language that lets you concatenate strings. The usual fix is a max size on such strings. There are a couple of other potential vulnerabilities, such as the ability to access the content of any URL, including file://etc/group, but again JavaScript has that too.
- namedgraph 6y agoExactly
- retrofuturism 6y agoLet’s deprecate old technologies that are currently bundled in web browsers instead of adding to them. Browsers need to go on a diet.
- znpy 6y agobrowsers 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 browser. it really suffices one badly-coded app (not using well asynchronicity and/or wasting memory) to make the whole browser appear slow.
- cesarb 6y agoNo, 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.
- coldtea 6y agoUsually most of the size is various UI assets, not features.
- barefootliam 6y agoHere at least, firefox depends on libxml2, which comes from a different package. But, bloated is in the eye of the beholder - there's always Dillo and lynx.
- stjohnswarts 6y agoWhich break on tons of sites because they simple can't render them and never will. That bloat isn't really bloat because it is necessary to handle what modern users want it to handle. Browsers aren't going to probably ever "diet" again. They'll only remove insecure features.
- ferdowsi 6y agoThe Google team is right. It had a great run, but it's time to let XML die.
- netfl0 6y agoHave they proposed an alternative?
- nimish 6y agoHTML and JavaScript. Works for PDF with PDF.js XML is no longer relevant to the modern web
- netfl0 6y agoI can’t tell if this was a serious response, I am not trying to pull your leg.
- nimish 6y agoIt’s a very serious response. XML is a defective technology that has no place in the modern web. Perhaps the only successful bit is SVG, for lack of a better alternative. MathML is a failure — katex and mathjax do a fundamentally better job of rendering mathematics on the web — and are based on what people who write a lot of math actually use: tex and friends. If you need to interpret XML documents as HTML, use some javascript. The attack surface reduction of eliminating XPath, XHTML, XSLT and other mistakes like microformats is worth it alone. I stand by this, having implemented enough of XPath, XML 1.1 and XSLT to implement WS-Security from scratch (have fun with c14n!). The sooner we move on from the failed experiment of XHTML, the better. The idea that the browser is the means of extending the core document model is gone; most if not all power resides in the JS engine. If it makes sense to stick in the core browser engine, then it will be obvious when that is so via usage statistics. You can compile libxml2 to wasm if you must (i’ve done this when I needed a more complete XPath implementation)
- 6y ago
- zorked 6y agoThis is an editorialized link name and the target comment isn't even obviously wrong or anything. Let the awfully outdated XML tooling die. Context: This was named "Chrome holding the web back: an example", I expect moderation will change this at some point to something like "Chrome unlikely to support XPath 3.1" which is considerably less incendiary and something few people here care about.
- augusto-moura 6y agoMore like: "Chrome unlikely to follow WHATWG XPath 2.0+ support spec if ever merged" Or "Chrome devs being against XPath 2+ spec because of internal maintenance problems"
- jeffbee 6y agoi guess the non-inflammatory title would be “representative of chrome project votes no in one of many working group proposals “?
- josephcsible 6y agoThey didn't just vote no. They basically said they're not implementing it even if everyone else votes yes.
- jeffbee 6y agoLike my mother used to say: if all of your friends jumped off a bridge, would you jump too?
- somehnguy 6y agoPlease 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.
- richx 6y agoI 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.
- vfclists 6y agoNo one addresses why the company that dominates web search should have an outsize influence on standards in an area where it has an obvious conflict of interest in adopting technologies that _may_ empower potential competitors, aka ie the rest of the world.
- anderspitman 6y agoAs of the last couple years, Chrome is the web. The writing has been on the wall since at least Widevine. The browser wars are over, and I don't see any scrappy startup crossing the moat of complexity GOOG has built around "modern" browsers. Especially when combined with their stranglehold of the standards committees. We need to find a new attack vector.
- rangoon626 6y agoThey’ll do it to themselves. One thing I see regularly is Chrome’s web caching being so aggressive it is driving front-end developers to start using FF for dev. We simply need to stand back and let time take its course.
- kgwxd 6y agoDoes Chrome no longer have the option to disable cache while dev tools is open?
- 9HZZRfNlpR 6y agoIt sure does and it works, not sure how or what use case the parent has problems with. Would be quite interesting to find out.
- rangoon626 6y agoOh, 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 thing that I should have mentioned is with non-dev staff. When new builds and updates get pushed out, they often have problems because of Chrome's aggressive caching. This group isn't as privy to knowing about developer tools and chaching, and it is highly frustrating and annoying for them. It seems like they will still use Chrome for casual browsing, but then start to use Firefox or Safari for testing builds. I use Firefox 100% of the time and very very rarely have these kinds of issues. All I can say is that something is seriously wrong with Chrome's caching policy, from a UX perspective. People do get frustrated in ways that they don't when using Safari or Firefox.
- fouc 6y agoI feel like XPath queries have been gaining more widespread usage over the last decade by developers at the css/javascript level, so perhaps it makes sense to improve the power of it.
- masklinn 6y agoThere is no need to improve the power of xpath in browsers, they already have a scripting langage, they don’t need a second one. What would be useful however is improving the precision, xpath 1.0 had a pretty restricted set of functions which hampers filtering, you either need to bring too much back to JS or the selector becomes overly complex with painful cross-language escaping, especially when dealing with HTML trees (token lists are really painful to deal with just 1.0’s functions set). Making exslt & applicable later functions available would be a huge boon without needing to change the langage itself.
- xaduha 6y agoThis discussion is a decade late. The direction was set when HTML5 was chosen instead of XHTML 2.0 and I don't think any important group changed their mind since. Committee-made standards are impotent without popular implementations.
- aravindet 6y agoFor those replying with "XML is bad and therefore Google is right", reading the whole thread presents a more complex picture. Quoting from various comments in that thread, > this is a proposal for querying the HTML DOM with XPath, not XML. > Per https://www.chromestatus.com/metrics/feature/popularity https://www.chromestatus.com/metrics/feature/popularity it does seem that about 1-2% of page views end up using XPath One could argue whether a feature that has existed for over a decade and is only used by 1-2% of page views is worth improving, but that is not the argument that domenic is making here. > Chrome is not interested in this. The XML parts of our pipeline are in maintenance mode... > By "XML parts of our pipeline" I mean "everything implemented using libxml and libxslt". His comment is that in the Chrome codebase, the XPath implementation is within some XML libraries, which are in maintenance mode. This may or may not be true for other browsers. It's interesting that these refer only to the implementation cost to Google, and does not make any reference to costs or benefits to other users of the web platform, which are discussed by other comments. Overall, while there seem to be valid arguments both for and against the proposal, arguments for are being presented publicly in that thread while those against are being discussed elsewhere (perhaps at Google?), with only final, unchallengeable decisions being posted here. Domenic is fairly explicit in his refusal to engage in a discussion. > As such, I won't be participating in this thread further. I think I've made our position clear. Irrespective of whether you agree with the proposal itself, to an outsider like myself it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms. Edit: moved a paragraph for clarity
- halflings 6y ago> does not make any reference to costs or benefits to other users of the web platform > arguments for are being presented publicly in that thread while those against are being discussed elsewhere (perhaps at Google?) It's right there at the end of the highlighted comment: "we would love to [...] replace them with something that generates less security bugs. Increasing the capabilities of XML in the browser runs counter to that goal." So security bugs in XML seems to be the main issue?
- richx 6y ago
- chrismorgan 6y agoDiscussion 19 days ago: https://news.ycombinator.com/item?id=24765868 https://news.ycombinator.com/item?id=24765868
- dang 6y agohttps://news.ycombinator.com/item?id=24940676 https://news.ycombinator.com/item?id=24940676 is also related.
- petters 6y agoI thought XPath was terrible beyond 1.0? E.g. https://tomforb.es/xcat-1.0-released-or-xpath-injection-issues-are-severely-underrated/ https://tomforb.es/xcat-1.0-released-or-xpath-injection-issu... But it does not seem to be mentioned as an argument.
- zmix 6y agoXPath beyond 1.0 can do the same things, that XPath 1.0 could do. You still can do your nifty one-liners. But it can do so much more now! Especially since it is a subset of XQuery now, and that's where things become very interesting.
- throw_m239339 6y agoI mean some people working on Chrome tried to remove XSL support at some point: https://bugs.chromium.org/p/chromium/issues/detail?id=514995 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 Chrome and Safari left and see what happens to web "standards"...
- bawolff 6y agoI dont know, i think im biased against it because i have touched it (even of xslt is quite cool)
- LaserToy 6y agoI 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
- dathinab 6y ago> 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 sub-set of XML, i.e. XML reinvented in 2020 would probably be better then YAML. But then you could also do a YAML reinvented in 2020 ;=)
- barefootliam 6y agoWhen 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 were people with large, complex, or multitudinous documents. There's also microxml, although its traction is limited because of a (relatively minor) backward compatibility issue around whitespace in attribute values. The use case of people editing small simple documents by hand, documents that did not contain mixed content (rich text if you like, with markup inside running text) wasn't major; in creating XML we did discuss having a syntax that distinguished elements that could contain text directly from those that could only contain other elements, but none of the suggestions were compatible with HTML, of course, or any other existing SGML vocabulary, and all of the proposals (including mine) were ugly and had flaws. The primary advantages of using XML are * you can use the XML stack - XPath, XSLT, XQuery, RelaxNG, XML Schema, XForms, EXI, etc etc - on your documents (including conf files) * people who don't think of themselves as programmers can do sane powerful & useful things - the languages are declarative; * XML documents can be in the problem domain - elements named after things they represent, not "div" and "span" for example * 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; * 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) For sure there are things we'd do differently with hindsight, but remember also that XML predates the success of JavaScript and CSS. There are things that would be different in JavaScript and CSS today, too, if done again.
- richx 6y agoThe European Securities and Exchange Commission (ESMA) has just now mandated all listed companies in the EU to publish their annual financial statements in XHTML instead of PDF or paper. Combined with XBRL taxonomies it’s a very powerful structured format. Please don’t forget that XML is widespread in business applications and I haven’t seen any similar powerful replacement for XML validation and XPath. Please let me know if you know one.
- barefootliam 6y agoThere isn't an alternative, largely i think because XML people come at the problem from the idea that documents are primary, not just artifacts of programs.
- zmix 6y agoVery good comment. I wholeheartedly agree. Also, there is a whole world outside of software development: The world, that uses this software. And that world produces documents, that need to be managed. And those, who manage them, are users, not programmers.
- namedgraph 6y agoData-driven architecture is the future. Data has to be driving the software, not the way around.
- rhacker 6y agoWould have been less controversial if they just rename it to hpath.
- csours 6y agoI feel like a real dummy right now... Aren't modern web pages xhtml??? Isn't xhtml xml??? Removing support for XPath kills MANY tests. I feel like a crazy person. Can someone help with context?
- goto11 6y agoModern web pages are HTML. You can write HTML in a way that it is compliant with the XHTML standard and therefore also valid XML, but it will still be rendered by the HTML engine in the browser, not the XML engine.
- dathinab 6y agoNo, xhtml died. Pages are html and not neccessary xml compatible. XPath is used for html independent of xml (because the structure is very similar and as such querying html with xml based query systems can work). But for google it's part of their xml code base they don't want to touch.