Safari 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
I 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 detect…
Chrome unlikely to support XPath 3.1
71–80 of 114 posts
Re: Chrome unlikely to support XPath 3.1
#72Earlier quoted context omitted.
Don’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!
Have you misunderstood me? MathML does not work well even in Safari and Firefox, and that is why they are avoided.
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.
Re: Chrome unlikely to support XPath 3.1
#73For 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 it does seem that about 1-2% of page views end up using XPath One could argue whether a feature that has existed for o…
> 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. > 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. A few months back Chrome…
Re: Chrome unlikely to support XPath 3.1
#74Earlier quoted context omitted.
> 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 count…
I’m wondering which security risks they mean. I don’t see any security risk in XML itself, maybe it’s related to some XPath or XQuery functions?
Re: Chrome unlikely to support XPath 3.1
#75The 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…
Re: Chrome unlikely to support XPath 3.1
#76Earlier quoted context omitted.
> 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 count…
I’m wondering which security risks they mean. I don’t see any security risk in XML itself, maybe it’s related to some XPath or XQuery functions?
Re: Chrome unlikely to support XPath 3.1
#77Earlier quoted context omitted.
> 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. > 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. A few months back Chrome…
I am not sure we can fix the web until other browsers actively treat Chrome developers as a hostile entity. Firefox and Edge teams have both been repeatedly screwed by the assumption their counterparts at Google were acting in good faith.
Re: Chrome unlikely to support XPath 3.1
#78Earlier quoted context omitted.
It sure does and it works, not sure how or what use case the parent has problems with. Would be quite interesting to find out.
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…
Re: Chrome unlikely to support XPath 3.1
#79Earlier quoted context omitted.
Safari 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/mediasource
Safari 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.
Re: Chrome unlikely to support XPath 3.1
#80Earlier 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…
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.