Open verdy-p opened 4 days ago
Josh-Cena
commented
3 days ago You are right that the example is wrong, because we don't support rendering SVG in live examples, so we typically get away with just rendering it as HTML, which usually works, but not here—we should fix that. However xml:space is deprecated in spec. See https://svgwg.org/svg2-draft/struct.html#WhitespaceProcessingXMLSpaceAttribute.
verdy-p
commented
3 days ago There's the same issue for the standard "xml:lang" pseudo-attribute or "xlink:*" attributes (valid with proper namespace declaration), which are standard in XML but not supported and should have no effect in HTML (notably in selectors used with CSS), unless the document is serialized with the XHTML syntax and not with HTML5.
So if you want to make live demos, you'd need to use XHTML-type documents, not HTML-type documents. These demos should go to separate doc pages about XML processing (e.g. with XSLT).
As well you should not say that you are documenting "SVG2", you are just documenting the "svg" HTML element and its support in HTML renderers (browsers). The compatiblity table is also wrong, showing a support that does not exist (or that has already been removed after some initial legacy integration but that was experimental and was just wrong and not conforming to HTML), because of these confusion of separate specs.
Documentation for the support in true SVG renderers (based on XML parsers) has to be more cleanly separated from the support in browsers (based on HTML parsers).
MDN URL
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xml:space
What specific section or headline is this issue about?
everything
What information was incorrect, unhelpful, or incomplete?
All that page shows is wrong. This attribute is NOT deprecated at all. The demo given for HTML are just wrong! They show use of the HTML5 "svg" element, which is NOT the SVG standard itself. In HTML5 (encoded with the HTML syntax), there's NO support at all for XML, so XML pseudo-attributes are not recognized at all (and MUST not be recognized). Instead HTML5 defines a subprofile of SVG for the HTML5 "svg" element (which is just inspired from XVG, but which is NOT conforming to the SVG standard that must conform to XML).
So the live demos do not show any different when you use the XML pseudo-attribute, which makes no sense in the HTML5 syntax. And it is then normal that these demos do not display any difference if you use it or change the value.
A true demo for the SVG standard would use an true SVG document (embedded in a separate document as an HTML "object" element, parsed by a conforming XML parser, and not by the HTML5 parser, and generating its own independant DOM!). But the demo uses the HTML5 "svg" element which is NOT defining any new document, but integrates some SVG-like features in the HTML DOM, with known limitations.
In summary: the HTML5 specification about its support of the "svg" element is NOT the specification of the SVG standard itself (not SVG 2.0 and not any existing SVG version).
Stop that confusion! Webbrowsers or actual SVG renderers kwow the differences. These are two kinds of document types with separate specifications. The SVG standard is much MORE powerful than what HTML5 provides and allows in its (voluntarily limited) "svg" element.
The SVG2.0 has NEVER dropped/deprecated the basic XML conformance requirements, which are still also valid if you encode an HTML5 page into XML (with XHTML) with a different document type, a different syntax and that supports many things that HTML5 does not allow: it is possible to transport an HTML5 document in XML, where you can also integrate SVG documents instead of referencing them. If you do that, the conversion of HTML5's "svg" to XML is quite easy, but any "xml:*" pseudo-attributes that are invalid in HTML5's syntax will also be ignored and dropped in the converted XHTML document.
The XHTML syntax is still very useful to expose the HTML5 parsed DOM, and all its possible transforms made within the browser when it will try to embed and adapt the referenced external documents or when the runtime dynamic DOM maintained by the browser will be changed by other features (e.g. with the HTML DOM API accessed by scripts or modified implicitly by the web browser when handling events): the web browser maintains a different dynamic DOM which is NOT reencodable safely in HTML5, but dumpable in XHTML (using standard XML). But HTML5 is just a very reduced form of document which is intrinsically static and has strong limitations (so that browsers are much more free to build their implementation when they will build their real internal DOM as exposed by the DOM API, but whose current working state is NOT serializable into HTML5, but only into XML/XHTML).
What did you expect to see?
Remove all refererences to the SVG or XML standards. They are NOT relevant to the HTML standrd itself. Instead document separately the SVG standard, where XML is a mandatoty foundation base.
Do you have any supporting links, references, or citations?
No response
Do you have anything more you want to share?
No response
MDN metadata
Page report details
* Folder: `en-us/web/svg/attribute/xml_colon_space` * MDN URL: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/xml:space * GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/svg/attribute/xml_colon_space/index.md * Last commit: https://github.com/mdn/content/commit/a7615ee2f9e22946edff7633962bc1d9eee9e0ad * Document last modified: 2024-07-25T22:03:15.000Z