HN user

Fileformat

824 karma

https://andrew.marcuse.info/

meet.hn/city/us-Philadelphia

Posts19
Comments146
View on HN
www.rss.style 6mo ago

Show HN: RSS.Style – better UX for RSS/Atom links, now using JS instead of XSLT

Fileformat
6pts0
www.rss.style 1y ago

Show HN: RSS/Atom Feed Analyzer – test your feed for best practices

Fileformat
3pts0
www.sitemap.style 1y ago

Show HN: XSLT and graphical outline viewer for your sitemap.xml

Fileformat
5pts0
andrew.marcuse.info 1y ago

Show HN: Comparing Docker minimal image size for a JSON API in various languages

Fileformat
2pts3
www.youtube.com 1y ago

Fearsome File Formats by Ange Albertini (YouTube) [video]

Fileformat
1pts0
en.wikipedia.org 1y ago

Buying Wikipedia

Fileformat
6pts1
news.ycombinator.com 1y ago

Ask HN: Any Recommendations for Logo APIs?

Fileformat
1pts2
github.com 1y ago

Show HN: Ghashboard is a dashboard builder for GitHub Actions

Fileformat
2pts0
oldcrap.org 1y ago

Old Crap Vintage Computers

Fileformat
11pts0
www.feed.style 2y ago

Show HN: Feed.style – better UX for RSS and Atom news feed links

Fileformat
4pts0
www.filfre.net 4y ago

A Web Around the World, Part 8: The Intergalactic Computer Network

Fileformat
11pts0
resolve.rs 5y ago

Show HN: Comparison of IP Geolocation services and databases

Fileformat
6pts5
which.nameserve.rs 5y ago

Show HN: Which DNS servers are you pointing to?

Fileformat
283pts96
iconsear.ch 5y ago

Show HN: Instant SVG icon search with over 50K+ icons indexed

Fileformat
53pts5
queue.acm.org 5y ago

The Life of a Data Byte

Fileformat
2pts0
logosear.ch 6y ago

Show HN: Instant search of 200K+ SVG logos from 100 sources

Fileformat
251pts45
www.vectorlogo.zone 7y ago

Show HN: Vector Logo Zone – SVG logos for your readme or credits page

Fileformat
275pts47
www.vectorlogo.zone 8y ago

Show HN: VectorLogoZone – Consistent SVG Vector Logos

Fileformat
1pts2
www.heatmap.tv 8y ago

Show HN: HeatMap.TV – Realtime Google Analytics Heatmap for Big-Screen TVs

Fileformat
51pts17

<self promotion>

One thing that would be nice is to have the feed be human readable. It is as easy as adding a single line to the XML and setting the content type [1].

Your feeds are also missing a bunch of the headers that readers use to avoid over-fetching your feeds. I build an feed analyzer [2] to help debug things like this.

[1] https://www.rss.style/

[2] https://www.rss.style/feed-analyzer.html

</self promotion>

RSS.style is my site. I'm currently testing a JavaScript-based workaround that should look just like the current XSLT version. It will not require the XSLT polyfill (which sort-of works, but seems fragile).

One bonus is that it will be easier to customize for people that know JavaScript but don't know XSLT (which is a lot of people, including me).

You'll still need to add a line to the feed source code.

There wasn't free hosting in 2003 when I first made it. I have thought about converting it to static, but it would be a complete rewrite, and there is always some other new shiny thing to play with instead.

The newer things I'm doing (like UnicodeSearch.org) are static, though I don't like forcing everyone to have JavaScript enabled.

I get where you are coming from, and have put some thought into it.

I built the site over 20 years ago, and while it was fun to make, I wouldn't have maintained it this long if is was costing me every month.

I've tried to minimize the intrusiveness: I disabled the pop-up and interstitial ads and I don't serve anything different to people with ad-blockers. And I've stuck with Google Adwords, despite requests from all sorts of questionable alternatives.

I'm not sure about the future: bots are causing all sorts of trouble, and the ad revenue is trending down and is now less than break even.

I run a couple similar sites:

FileFormat.Info[1] has a page per codepoint. It has been around awhile, so the UI isn't as whizzy, but it has all the data and works w/o JavaScript

UnicodeSearch[2] is an updated search UI that uses JavaScript and the excellent Tabulator grid widget.

There are actually a ton of similar sites with a page-per-codepoint. It is all fun to make one, until the bots come along and hammer every page.

[1] https://www.fileformat.info/info/unicode/char/2248/index.htm

[2] https://www.unicodesearch.org/

And these aren't niche/advanced features? I'm using Firefox now, and did not know about them. If I'm using them, it is only accidentally or because they are the defaults.

But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.

I agree with you. But a typical consumer will already be using Chrome, and has no reason to use Firefox.

If one of these advanced/niche technologies takes off, suddenly they will have a reason to use Firefox.

I don't disagree with you, but given (A) how will Firefox ever compete?

One possible way is doing things that Google and Chrome don't (can't).

Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete.

Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).

Which is why Firefox is steadily losing market share.

If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.

Not to mention a built-in ad-blocker...

That is not the point: I already have the blog's HTML pages. I want the RSS feed to be an RSS feed, not another version of the HTML.

The XSLT view of the RSS feed so people (especially newcomers) aren't met with a wall of XML text. It should still be a valid XML feed.

Plus it needs to work with static site generators.

You are absolutely right!!! But...

What about people who don't "1) Know what RSS is"???

And what if you could make it friendly for them in 4 minutes? You could by dropping in a XSLT file and adding a single line to the XML file. I bet you could do it in 3 minutes.

But you are tech-savvy and know about RSS & feed readers and such like!

Think about it from a non-technical user's perspective: they click on a RSS link and get a wall of XML text. What are they going to do? Back button and move on. How are they ever going to get introduced to RSS and feed readers and such like?

I think a lot of feeds never get hit by a browser because there isn't a hyperlink to them. For example: HN has feeds, but no link in the HTML body, so I'm pretty confident they don't get browser hits. And no one who doesn't already know about feeds will ever use them.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that.

I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user?

https://www.rss.style/

I think that "market demands" is a bit of a misnomer. RSS was (and remains) too tech-y for the mainstream.

If browser vendors had made it easy for mainstream users, would there have been as much "market demand"?

Between killing off Google Reader and failing to support RSS/Atom, Google handed social media to Facebook et al.

XSLT RIP 8 months ago

Well, I do agree with you, but...

1. This is pretty difficult for someone who doesn't know about RSS. How would they ever learn what to do with it?

2. Browsers don't do that. There used to be an icon in the URL bar when they detected an RSS feed. It would be wonderful if browsers did support doing exactly what you suggest. I'm not holding my breath.

I'm not looking to replicate my blog via XSLT of the RSS feed: that's what the blog's HTML pages are. I just don't want to alienate non-RSS users.

XSLT RIP 8 months ago

Huh? How would a static site generator serve both RSS and the HTML view of the RSS from the same file?

To be extra clear: I want to have <a href="feed.xml">My RSS Feed</a> link on my blog so everyone can find my feed. I also want users who don't know about RSS to see something other than a wall of plain-text XML.

XSLT RIP 8 months ago

I want to use it on an RSS feed: to make it sensible when a new users clicks on an RSS link.

I specifically want it to be served as XML so it can still be an RSS feed: I don't even need the HTML to look that great: I have the actually website for that.

Example: https://www.fileformat.info/news/rss.xml

XSLT RIP 8 months ago

Because we want RSS to be friendly to new users. If you display a RSS feed as a wall of XML text, no new user will understand. If you just make it so clicking a RSS link brings up a blurb about RSS is & links on how to use, they might understand.

And we have done it for other formats: PDF is now quite well supported in browsers without plugins/etc.

1. Everyone who uses a static site generator can add XSLT

2. Everyone who doesn't use a static site generate only has to add the XSLT file and add a single line to the XML. No need to write any code: new code is not a big deal for many HN readers, but not every blog author is a coder.

That's my point: you know all about RSS & feeds and don't need it. But what about someone who hasn't been using them since the beginning?

I think every page with an RSS feed should have a link to the feed in the html body. And it should be friendly to people who are not RSS wizards.

One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use.

I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link.

But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish).

XSLT is currently the only way to make feeds into something that can still be viewed.

I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO).

I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/

You can see it in action on an RSS feed here (served as real XML, not HTML: do view/source): https://www.fileformat.info/news/rss.xml

This is exactly my point: everyone here is tech-savvy and knows what to do with an RSS/Atom link. So we don't see a need for XSLT.

But someone who hasn't seen/used an RSS reader will see a wall of plain-text gibberish (or a prompt to download the wall of gibberish).

XSLT is currently the only way to make feeds into something that can still be viewed.

I think RSS/Atom are key technologies for the open web, and discovery is extremely important. Cancelling XSLT is going in the wrong direction (IMHO).

I've done a bunch of things to try to get people to use XSLT in their feeds: https://www.rss.style/

You can see it in action on an RSS feed here (served as real XML, not HTML): https://www.fileformat.info/news/rss.xml