5 ms·

Isn't the fundamental issue here not so much anything to do with `<svg>`, but with the fact that you can't easily include HTML snippets from other files in HTML

by OskarS 2y ago

Isn't the fundamental issue here not so much anything to do with `<svg>`, but with the fact that you can't easily include HTML snippets from other files in HTML? Like, the only reason not use the <svg> tag seems to be "it's not cached, and it contains a BUNCH of svg, and it has to be loaded with the main HTML page" Can't you say that about anything in HTML? Like, imagine you had a huge `<head>` tag that contained a bunch of stuff, but it's essentially the same (except for, like, the title) for all documents. Don't you wanna do this? <html> <head> <<< include head.html >>> <title>Cool page!</title> </head> <body> <svg> <<< include logo.svg >>> </svg> </body> <html> Where the `<<< include ... >>>` is a pretend bit of HTML that makes the browser fetch that from somewhere else. A preprocessor, more or less. I realize this is what templating languages are for, but if this happened on the HTML layer, the browser could do way better caching.

panstromek 2y ago
Yes, I want this and it would solve quite a few issues - particularly lazy loading and SPA-style content swapping could be done with better performance, because html can be easily processed and rendered during download by the browser (unlike the classic AJAX -> Json.parse -> render pipeline, which requires each step to be completed before the next one starts). Lazy loading would also not require JavaScript.
nbadg 2y ago
I think whether or not this makes sense on the client-side is up for debate. Alternatively, though, SVGs in ``<svg>`` elements could just, yknow, retain their stylability. (is there a reason they don't? this has been a long-running frustration of mine)
- cubefox 2y ago
  You mean <img>. <img> is not stylable.
ndriscoll 2y ago
HTML does have a preprocessor. It's called XSLT, and it has includes, though they have no deferred fetch. Also, being a preprocessor, you can't interact with it after page load (unless you use a javascript implementation). It's been built into browsers for 20+ years. Still works great, but browsers never supported versions past 1.0 so it shows its age some.
- kbolino 2y ago
  XSLT is an XML transformation language, but HTML is not XML. Does XSLT work on regular HTML?
  - dekhn 2y ago
    At the time HTML was converted from SGML to XML: https://en.wikipedia.org/wiki/XHTML https://en.wikipedia.org/wiki/XHTML so if you authored XHTML, you could XSLT it. There is also XHTML5, an XML serialization of HTML5. I imagine in the real world there is a great deal of web that is HTML, accepted by browser, but not XML.
    - kbolino 2y ago
      As far as I know, HTML5 has diverged from its origins enough that it's neither SGML nor XML. However, given the existence of XHTML5, it might be possible to parse an HTML5 DOM and re-serialize it as XHTML5, and thus it might be possible to take parseable HTML as input to XSLT, albeit with some indirection.
  - ndriscoll 2y ago
    I'm not sure what you mean, but you can output HTML that a browser will be happy with, and that conforms to the spec. See e.g. https://stackoverflow.com/questions/3387127/set-html5-doctype-with-xslt https://stackoverflow.com/questions/3387127/set-html5-doctyp...
    - kbolino 2y ago
      As I understand XSLT, it takes an XML document as input and an XML document describing the transformation, and produces an XML document as output. But most HTML in the wild today is not valid XML. There is XHTML as mentioned by a sibling comment but it's rarely used. So if you were to start with an existing base of HTML documents, you couldn't easily add XSLT preprocessing to them. The issue is with the input rather than the output.
jwells89 2y ago
To me at least this feels like a fairly natural addition to HTML. You can already pull in external scripts, stylesheets, images, video, etc, so why not page partials too? A sibling comment mentions XSLT which is cool, but nobody knows about it because it doesn’t follow any patterns set in HTML and HTML doesn’t have any breadcrumbs that might lead someone to discover XSLT. Something like <partial src=“header.html”> flows with expectations much better. Something I find a bit funny now is that for the longest time back in the 2000s, nearly the entirety of my usage of PHP was comprised of PHP includes to make up for this gap in HTML functionality (I had no idea XSLT existed then).
- ndriscoll 2y ago
  It had breadcrumbs back in 2004 (e.g. those neat "valid XHTML 1.1" badges from W3C back when badges on your website were cool, and e.g. W3 Schools actually put it above javascript[0]. XHTML was supposed to be the next big thing). These days it seems that browser vendors just don't like it for whatever reason (tinfoil hat on: because almost all of them benefit from javascript-based spyware, and so prefer a world where even static pages require javascript to be enabled to show anything), and so documentation acts like it is some legacy thing instead of what it is: a perfect fit for the 99% of websites that need some templates and don't have much dynamic interaction. Other cool web tech that should have "won": XForms[1]. Imagine if HTML forms had things like declarative data-binding (with XPath expressions! Imagine jq built directly into the browser 20 years ago and usable by forms) and types/constraints/validation built right in. This would be 1000x more useful for your average web dev than something like USB or GPU support or Wasm. You'd be able to make complex interactive forms in much the same way that you do a spreadsheet. [0] https://web.archive.org/web/20040727061732/http://www.w3schools.com/ https://web.archive.org/web/20040727061732/http://www.w3scho... [1] https://www.youtube.com/watch?v=2yYY7GJAbOo https://www.youtube.com/watch?v=2yYY7GJAbOo
- PaulDavisThe1st 2y ago
  One reason that this is slightly more complicated than it appears is that you have to decide what ignore when doing the inclusion. Including an image will not override anything specified in the "parent" HTML, but including HTML might result in conflicts. Who wins, who loses, etc. etc.
danbee 2y ago
Turbo Frames (https://turbo.hotwired.dev/handbook/frames https://turbo.hotwired.dev/handbook/frames) does this. It does mean pulling in a JavaScript library (and the user having JS enabled) but you don't have to write any. I'd definitely love to see something like this built into the browser.
tannhaeuser 2y ago
HTML was invented as an SGML vocabulary, and SGML does have those inclusion mechanisms (called entities), though browsers basically never implemented those. To this date, self-acclaimed web folks ridicule XML (a simplified subset of SGML originalky invented as the base for additional vocabularies on the web, of which SVG and MathMl made it) for daring to incorporate something as basic as text variables/entities ie the "billion laughs atrack" (SGML could already limit the recursive entity expansion depth).
spankalee 2y ago
There's this HTML spec issue for an include feature that I think could always use more support: https://github.com/whatwg/html/issues/2791 https://github.com/whatwg/html/issues/2791 One of the things said in there is that they look for usage of userland solutions. I mentioned in another comment, but there are custom elements that do client-side includes, like: https://www.npmjs.com/package/html-include-element https://www.npmjs.com/package/html-include-element
recursive 2y ago
We had this 25 years ago in the form of "Server Side Includes". https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes You could put something like this in your markup  And the web server would apply it and inline the contents. It had a bunch of other directives, but this was the good one.
- spankalee 2y ago
  A server side include wouldn't fix this problem because the SVG would be inlined everywhere. That defeats caching by duplicating the content.
  - Izkata 2y ago
    If we're talking just SVG, it could be done as a one-time inlining that uses <defs> to define shapes, that get pulled into the page later with <use>. The defs are page-wide and work across <svg> elements. That would fix the duplication, though not necessarily caching on its own with GP's include. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs https://developer.mozilla.org/en-US/docs/Web/SVG/Element/def...
tracker1 2y ago
I may be completely off and/or misremembering, but isn't this what <object> was meant to be able to do/support? Seems that this could be done by convincing Apple/Google/Firefox to reframe/update how the object element works in modern browsers.

by OskarS 2y ago

panstromek 2y ago

Yes, I want this and it would solve quite a few issues - particularly lazy loading and SPA-style content swapping could be done with better performance, because html can be easily processed and rendered during download by the browser (unlike the classic AJAX -> Json.parse -> render pipeline, which requires each step to be completed before the next one starts). Lazy loading would also not require JavaScript.

nbadg 2y ago

I think whether or not this makes sense on the client-side is up for debate. Alternatively, though, SVGs in ``<svg>`` elements could just, yknow, retain their stylability. (is there a reason they don't? this has been a long-running frustration of mine)

cubefox 2y ago
You mean <img>. <img> is not stylable.

ndriscoll 2y ago

HTML does have a preprocessor. It's called XSLT, and it has includes, though they have no deferred fetch. Also, being a preprocessor, you can't interact with it after page load (unless you use a javascript implementation). It's been built into browsers for 20+ years. Still works great, but browsers never supported versions past 1.0 so it shows its age some.

kbolino 2y ago
XSLT is an XML transformation language, but HTML is not XML. Does XSLT work on regular HTML?
- dekhn 2y ago
  At the time HTML was converted from SGML to XML: https://en.wikipedia.org/wiki/XHTML https://en.wikipedia.org/wiki/XHTML so if you authored XHTML, you could XSLT it. There is also XHTML5, an XML serialization of HTML5. I imagine in the real world there is a great deal of web that is HTML, accepted by browser, but not XML.
  - kbolino 2y ago
    As far as I know, HTML5 has diverged from its origins enough that it's neither SGML nor XML. However, given the existence of XHTML5, it might be possible to parse an HTML5 DOM and re-serialize it as XHTML5, and thus it might be possible to take parseable HTML as input to XSLT, albeit with some indirection.
- ndriscoll 2y ago
  I'm not sure what you mean, but you can output HTML that a browser will be happy with, and that conforms to the spec. See e.g. https://stackoverflow.com/questions/3387127/set-html5-doctype-with-xslt https://stackoverflow.com/questions/3387127/set-html5-doctyp...
  - kbolino 2y ago
    As I understand XSLT, it takes an XML document as input and an XML document describing the transformation, and produces an XML document as output. But most HTML in the wild today is not valid XML. There is XHTML as mentioned by a sibling comment but it's rarely used. So if you were to start with an existing base of HTML documents, you couldn't easily add XSLT preprocessing to them. The issue is with the input rather than the output.

jwells89 2y ago

To me at least this feels like a fairly natural addition to HTML. You can already pull in external scripts, stylesheets, images, video, etc, so why not page partials too? A sibling comment mentions XSLT which is cool, but nobody knows about it because it doesn’t follow any patterns set in HTML and HTML doesn’t have any breadcrumbs that might lead someone to discover XSLT. Something like <partial src=“header.html”> flows with expectations much better. Something I find a bit funny now is that for the longest time back in the 2000s, nearly the entirety of my usage of PHP was comprised of PHP includes to make up for this gap in HTML functionality (I had no idea XSLT existed then).

ndriscoll 2y ago
It had breadcrumbs back in 2004 (e.g. those neat "valid XHTML 1.1" badges from W3C back when badges on your website were cool, and e.g. W3 Schools actually put it above javascript[0]. XHTML was supposed to be the next big thing). These days it seems that browser vendors just don't like it for whatever reason (tinfoil hat on: because almost all of them benefit from javascript-based spyware, and so prefer a world where even static pages require javascript to be enabled to show anything), and so documentation acts like it is some legacy thing instead of what it is: a perfect fit for the 99% of websites that need some templates and don't have much dynamic interaction. Other cool web tech that should have "won": XForms[1]. Imagine if HTML forms had things like declarative data-binding (with XPath expressions! Imagine jq built directly into the browser 20 years ago and usable by forms) and types/constraints/validation built right in. This would be 1000x more useful for your average web dev than something like USB or GPU support or Wasm. You'd be able to make complex interactive forms in much the same way that you do a spreadsheet. [0] https://web.archive.org/web/20040727061732/http://www.w3schools.com/ https://web.archive.org/web/20040727061732/http://www.w3scho... [1] https://www.youtube.com/watch?v=2yYY7GJAbOo https://www.youtube.com/watch?v=2yYY7GJAbOo
PaulDavisThe1st 2y ago
One reason that this is slightly more complicated than it appears is that you have to decide what ignore when doing the inclusion. Including an image will not override anything specified in the "parent" HTML, but including HTML might result in conflicts. Who wins, who loses, etc. etc.

danbee 2y ago

Turbo Frames (https://turbo.hotwired.dev/handbook/frames https://turbo.hotwired.dev/handbook/frames) does this. It does mean pulling in a JavaScript library (and the user having JS enabled) but you don't have to write any. I'd definitely love to see something like this built into the browser.

tannhaeuser 2y ago

HTML was invented as an SGML vocabulary, and SGML does have those inclusion mechanisms (called entities), though browsers basically never implemented those. To this date, self-acclaimed web folks ridicule XML (a simplified subset of SGML originalky invented as the base for additional vocabularies on the web, of which SVG and MathMl made it) for daring to incorporate something as basic as text variables/entities ie the "billion laughs atrack" (SGML could already limit the recursive entity expansion depth).

spankalee 2y ago

There's this HTML spec issue for an include feature that I think could always use more support: https://github.com/whatwg/html/issues/2791 https://github.com/whatwg/html/issues/2791 One of the things said in there is that they look for usage of userland solutions. I mentioned in another comment, but there are custom elements that do client-side includes, like: https://www.npmjs.com/package/html-include-element https://www.npmjs.com/package/html-include-element

recursive 2y ago

We had this 25 years ago in the form of "Server Side Includes". https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes You could put something like this in your markup  And the web server would apply it and inline the contents. It had a bunch of other directives, but this was the good one.

spankalee 2y ago
A server side include wouldn't fix this problem because the SVG would be inlined everywhere. That defeats caching by duplicating the content.
- Izkata 2y ago
  If we're talking just SVG, it could be done as a one-time inlining that uses <defs> to define shapes, that get pulled into the page later with <use>. The defs are page-wide and work across <svg> elements. That would fix the duplication, though not necessarily caching on its own with GP's include. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs https://developer.mozilla.org/en-US/docs/Web/SVG/Element/def...

tracker1 2y ago

I may be completely off and/or misremembering, but isn't this what <object> was meant to be able to do/support? Seems that this could be done by convincing Apple/Google/Firefox to reframe/update how the object element works in modern browsers.