Top
Best
New

Posted by caminanteblanco 21 hours ago

Nicu's test website made with SVG (2007)(svg.nicubunu.ro)
162 points | 91 commentspage 2
deepsquirrelnet 19 hours ago|
SVGs are under explored in generative AI. They are effectively a graphics language of their own. LLMs can write them directly without a vision architecture, and understand them in ways that non-vector graphics cannot.
youssefabdelm 19 hours ago||
One thing I love about SVGs for websites is their stability across many contexts, browsers, etc. Everything is pinpoint, coordinate based, nothing moves around unexpectedly. You define it once, it's done.
nine_k 11 hours ago|
If this is the goal, a PDF website could be even better.
anon1395 2 hours ago||
That is technically possible
anonyonoor 17 hours ago||
Has anyone ever built a document editor with SVG?

I realize it's far from a best practice and even explicitly stated as a bad idea somewhere in the SVG spec, but the idea of a document editor where you can individually position each and every character and make detailed, individual glyphs natively without loading fonts is interesting to me.

Are there any examples of this? Or perhaps different (better) approaches to a document editor with the advantages I said above?

PaulHoule 20 hours ago||
Viewed it on iPhone in the passenger seat of my son’s 79 Thunderbird. Doesn’t reflow and is a disaster in portrait but I pinch zoomed it in landscape and it was readable.
helf 20 hours ago|
[dead]
chuckadams 21 hours ago||
Text selection is sluggish and wonky in Firefox. A bit flickery in Chrome and Safari, but otherwise behaves fine.
chrismorgan 19 hours ago||
I do not observe any performance problem in Firefox (Nightly, Linux/Sway), and I’d say text selection is very good, with these caveats:

• Caret mode (F7) doesn’t work at all.

• Triple click selects all the text on the page, rather than just that of a single <text> element as I’d have expected (in which model you’d use <text> for a paragraph and <tspan> for its lines, and thus get the normal triple-click behaviour).

• Click and drag on a text link starts selection or drags the already-selected text, rather than dragging the link so you can drop it in a new tab or such. And if you mouse up on the same link (regardless of having left it), it activates.

• If you start a selection, it is only updated while you’re moving over text. Drag past the end of the line, then down, and it should select more text, but it only actually will when you move back over text.

• If text is selected, clicking outside text doesn’t clear the selection. (Probably the same root cause.)

• Shift+Up and Shift+Down select to the start or end of the containing <text> element, rather than operating linewise. (Because there’s no such thing logically, it’d require heuristic work. Or for people to implement flowed text, like Inkscape did but sadly then it was pulled out of the spec for some reason.)

There are also a couple of issues specific to this document:

• Document order is not sensible. For example, it goes title, then side nav title, then footer, then body text, then “Home”, then side nav contents, then magic keyword. But this does show a broader problem: in HTML it’s not the easiest to get stupid document ordering (possible, but you have to go a little out of your way), but in SVG it will happen unless you’re careful.

• Also likely to happen unless you’re careful: multiline text sometimes lacks the trailing spaces necessary to separate words once the line break is ignored (since there’s no such thing as a line break in SVG 1.1, only a shifted cursor position). For example, “Inkscapefor” fails, whereas “willing to” succeeds.

—⁂—

Chromium is interesting. Supports caret browsing (+), Up/Down do something weird (−), triple click only selects that <text> element (+), you can’t start a text selection in a link (±), but you can’t drag the link either (=), and while selecting, any time the pointer is not over text, it’ll shift that selection boundary to something like the start of the document (−), except it’s not actually the start because it excludes the title text for some reason.

jasonjmcghee 20 hours ago||
My experience in a chromium-based browser was multiline text selection was not good.

Any time you drag over space between lines, it selects something else.

chuckadams 20 hours ago|||
I think that's just the standard behavior of the selection algorithm with that particular layout. FF might be applying some kind of debouncing or hysteresis to keep it from flickering, but if so it's making all selection sluggish.
bobbylarrybobby 19 hours ago||||
Yes, unfortunately SVG does not support line breaks or wrapping, so much like pdf text selection is on a best effort basis
dylan604 20 hours ago|||
FF142 macOS had no issues with text selection on my end.

Yet another example of how maddening it still is when designing websites that have the same experience regardless of how it is viewed.

lpln3452 21 hours ago||
It's interesting that SVGs can include selectable text. Nice blog.
Karliss 21 hours ago|
Selectable and more importantly searchable text is one of the reasons why I occasionally open Large SVG diagrams in browser instead of the usual image viewer.
lpln3452 21 hours ago||
Right. I'd always just seen SVG as an image format. Interesting that browsers treat text inside them just like plain text.
DrewADesign 20 hours ago|||
I’ve done some cool things with the built-in SMIL animation too. You can control it with JavaScript and CSS… Watch out for the filters though — they can be pretty heavy compute-wise.
leptons 20 hours ago||||
You can actually embed HTML inside an SVG using the foreignObject element.
wild_egg 20 hours ago|||
I mean, it is just plain text inside some XML tags. It'd be weirder if they treated it like text in a photo
cf100clunk 21 hours ago||
The search term lmtbk4mh is found with Brave Search (3 hits so far, but it cannot provide a description of the SVG site). DuckDuckGo Search has zero results at this moment.
chrismorgan 20 hours ago||
The page is old enough that it wouldn’t surprise me if Google and Bing used to index it and are capable of indexing it, but no longer do. A lot of older stuff where you know exactly what’s there just can’t be found any more.

https://www.google.com/search?q=svg.nicubunu.ro seems to surface it, with text; https://www.google.com/search?q=site:svg.nicubunu.ro gets the title, but no more text. I’m curious how it decided what the title was. I wonder if they have some kind of “choose the largest text” heuristic if a title is missing.

https://duckduckgo.com/?q=svg.nicubunu.ro and https://duckduckgo.com/?q=site:svg.nicubunu.ro don’t show a result.

blahgeek 20 hours ago|||
I wonder if you copying the term here in HN (with the link to that site) would pollute the benchmark dataset…
cf100clunk 20 hours ago||
Good point. I wonder if that cat is now too far out of the bag for a deletion of my comments to be of help?
notpushkin 20 hours ago||
I don’t think it’s that big of a problem – you can still see if the results link to the SVG website itself, and ignore everything else.
cf100clunk 21 hours ago|||
There's symmetry at this moment in the results from Brave Search and Google Search looking for lmtbk4mh.
lblume 20 hours ago||
When searching for it on DuckDuckGo, the search engine found your comment via a HN frontend while not finding the original site.
aaaggg 20 hours ago||
Add GSAP DrawSVG (https://gsap.com/docs/v3/Plugins/DrawSVGPlugin/) and you've nearly rebuilt Macromedia Flash!
xnx 10 hours ago||
Small typo: "stuf"
muglug 21 hours ago|
Ah, reminds me of Flash websites with SEO-indexable text.
More comments...