5 ms·

For 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 t

For 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
  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?
  - barefootliam 6y ago
    I think more about the fact libxml and libxslt are large pieces of code and have had CVEs raised against them (and fixed) in the past. They are still actively maintained.
  - foota 6y ago
    I think the idea is the increased security risk of potentially poorly maintained large body of code with a wide surface area.
kerng 6y ago
1-2% of page views is pretty massive! Consider adjusting this number to remove any Google sites that are viewed (to remove Google's own bias/quasi browser monopoly) - and it probably goes up a lot more even.
- inimino 6y ago
  The number of pages with Flash content was also massive for many years. There must be some discipline to remove things from the web platform or it will die. XPath predates CSS selectors being exposed to JS, and it is absolutely clear that XPath had its best shot to move from niche to mainstream over a decade ago and it didn't happen.
  - namedgraph 6y ago
    Could a part of the reason that XPath stayed a niche technology that WHATWG and Google continuously chipped away at XML support and compatibility and shipped 20 year old implementations?
nwellnhof 6y ago
> His comment is that in the Chrome codebase, the XPath implementation is within some XML libraries, which are in maintenance mode. Chrome actually has two XPath engines. One is used for querying the HTML DOM with Javascript, the other one in libxml2 is only used for XSLT transformations. (XSLT support is the main reason why Chrome still uses libxml2. If they weren't relying libxslt which in turn requires libxml2, they would probably switch to a better suited XML parser like Expat or write their own.)
dmitriid 6y ago
> 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 shipped Constructible Stylesheets. The proposed specification was strictly opposed by other browser vendors, with Safari stating that they will not ever consider implementing them in the current state [1]. Chrome not only shipped it enabled by default, but refused to bring it back under a flag because "is used on about ~.8% of page loads in Chrome now" [1] (safe to assume, all of them are Google users and users of Google-developed libraries). It's the most recent example (also backed up by numbers provided by Google themselves). I won't even mention the plethora of standards that other browser vendors consider harmful, but are enabled by default in Google. So yes, Google is only concerned by the cost to Chrome, never by the costs or benefits to other users of the web platform. > it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms. That is true. The standards process (both w3c/whatwg and tc39) is hijacked by the same 3-4 people from Google, and decisions are rammed through irregardless of anyone. [1] https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-521096423 https://github.com/WICG/construct-stylesheets/issues/45#issu... [2] https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577781329 https://github.com/WICG/construct-stylesheets/issues/45#issu...
- ocdtrekkie 6y ago
  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.
  - dmitriid 6y ago
    This Twitter thread by Johnathan Nightingale talks about Google sabotaging Firefox: https://archive.is/tgIH9 https://archive.is/tgIH9
- 6y ago
londons_explore 6y ago
If only a tiny proportion of page views use XPath, it would seem it isn't performance critical. If that's the case, rewrite the whole lot into JavaScript, run it in the browser sandbox, and rip out the libxml that has security concerns. Then invite pull requests to add new versions of whatwg things. As soon as a browser API is written in JavaScript and only using other public API's, it becomes a near zero maintenance burden.

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
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?
- barefootliam 6y ago
  I think more about the fact libxml and libxslt are large pieces of code and have had CVEs raised against them (and fixed) in the past. They are still actively maintained.
- foota 6y ago
  I think the idea is the increased security risk of potentially poorly maintained large body of code with a wide surface area.

kerng 6y ago

1-2% of page views is pretty massive! Consider adjusting this number to remove any Google sites that are viewed (to remove Google's own bias/quasi browser monopoly) - and it probably goes up a lot more even.

inimino 6y ago
The number of pages with Flash content was also massive for many years. There must be some discipline to remove things from the web platform or it will die. XPath predates CSS selectors being exposed to JS, and it is absolutely clear that XPath had its best shot to move from niche to mainstream over a decade ago and it didn't happen.
- namedgraph 6y ago
  Could a part of the reason that XPath stayed a niche technology that WHATWG and Google continuously chipped away at XML support and compatibility and shipped 20 year old implementations?

nwellnhof 6y ago

> His comment is that in the Chrome codebase, the XPath implementation is within some XML libraries, which are in maintenance mode. Chrome actually has two XPath engines. One is used for querying the HTML DOM with Javascript, the other one in libxml2 is only used for XSLT transformations. (XSLT support is the main reason why Chrome still uses libxml2. If they weren't relying libxslt which in turn requires libxml2, they would probably switch to a better suited XML parser like Expat or write their own.)

dmitriid 6y ago

> 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 shipped Constructible Stylesheets. The proposed specification was strictly opposed by other browser vendors, with Safari stating that they will not ever consider implementing them in the current state [1]. Chrome not only shipped it enabled by default, but refused to bring it back under a flag because "is used on about ~.8% of page loads in Chrome now" [1] (safe to assume, all of them are Google users and users of Google-developed libraries). It's the most recent example (also backed up by numbers provided by Google themselves). I won't even mention the plethora of standards that other browser vendors consider harmful, but are enabled by default in Google. So yes, Google is only concerned by the cost to Chrome, never by the costs or benefits to other users of the web platform. > it looks like the process of discussion does not exist at WhatWG anymore, and that Google basically dictates terms. That is true. The standards process (both w3c/whatwg and tc39) is hijacked by the same 3-4 people from Google, and decisions are rammed through irregardless of anyone. [1] https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-521096423 https://github.com/WICG/construct-stylesheets/issues/45#issu... [2] https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577781329 https://github.com/WICG/construct-stylesheets/issues/45#issu...

ocdtrekkie 6y ago
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.
- dmitriid 6y ago
  This Twitter thread by Johnathan Nightingale talks about Google sabotaging Firefox: https://archive.is/tgIH9 https://archive.is/tgIH9
6y ago

londons_explore 6y ago

If only a tiny proportion of page views use XPath, it would seem it isn't performance critical. If that's the case, rewrite the whole lot into JavaScript, run it in the browser sandbox, and rip out the libxml that has security concerns. Then invite pull requests to add new versions of whatwg things. As soon as a browser API is written in JavaScript and only using other public API's, it becomes a near zero maintenance burden.