[BoardIndex.template.php] Webslices?

[StealthWombat]

`

', $context['forum_name_html_safe'], ' - ', $txt['recent_posts'], '

', $txt['subscribe_webslice'], '

';` Ok, webslices are IE-only. Why do we have IE-specific code in the markup? I realise that other browsers allow imitating webslices via plugins, but AFAIK they don't actually use the MS webslices shiz. Would it make more sense to enable an RSS feed for recent posts, or something?

[Spuds]

LOL ... I had noticed that some time back and had to look up what the heck they even were !

[StealthWombat]

Me too. And..............I looked up the entry-title and entry-content classes. They are effin' WordPress classes.

:ant: kill.

ETA: Have killed on local. Will be in next pile of stuffz, if someone doesn't PR it themselves first..

[norv]

Cool! :) Just to note, one thing that proves very useful sometimes in some 'wth' moments, is to look up old svn history and/or sm.org topics. It might come up with some reason long forgotten over time.

[norv]

I looked up the entry-title and entry-content classes. They are effin' WordPress classes.

Hmm, no. 'entry-title' and 'entry-content' are part of webslices, and hAtom on which it's based. (http://microformats.org/wiki/hatom)

Would it make more sense to enable an RSS feed for recent posts, or something?

A RSS feed is enabled, but webslices allow part of the page to be in a live feed in the browser (the recent posts part of board index), looking it up I found that Firefox addons were making it into live bookmarks. (untested). That said, I don't know if it works properly, in the spec the content shouldn't be an a link.

So why wouldn't it be there? Does it harm something? Our best bet would be to allow (not disallow) syndication with working specs. It sounded outdated to me, but looking it up I'm no longer sure it is the case.

[norv]

ETA: Have killed on local. Will be in next pile of stuffz, if someone doesn't PR it themselves first..

If we kill it, we should kill it everywhere. It's created in News controller in sources, and stuffs in Xml template. It doesn't seem used anywhere but recent posts when enabled, on board index. Leaving bits hanging would be the worst choice.

I don't have a suitable browser/addon combination at hand at the moment to test it live. The format is old, and it seems to not have got too much traction (others took over), but there are some uses and it's an open format. I'd suggest to let it be.

[StealthWombat]

Hmm. Ok, I'll look at it a bit closer. I was getting a bad feed warning off the thing, which is what got me wondering what it was. I'll see about doing a bit of testing on it, but if it never got much traction it seems a bit silly to have it. I'm on a mission to kill bloat. My 2c.

[Spuds]

I'm more in the remove it (everywhere) camp ... when I first came across it and looked up what the heck it was it just seemed like another idea that never gained much traction (like openID :angel:) Given its acceptance, and usage, it really feels like mod territory at best, how it ended up in the core I have no idea. My .02 or .01498 Euro

[StealthWombat]

Just looking at stuff again. The markup in the template was bonkers bloated, so I've stripped it down to what it needs, but left the feed (broken though it is) for the moment.

The classes I referred to have the same names as Atom attributes, but are WP classes. Since the stuff in question is display:none for presentation, having just one div with a sensible name would make more sense if we are keeping the thing.

The original, in full, is: `

', $context['forum_name_html_safe'], ' - ', $txt['recent_posts'], '

            <div class="entry-content" style="display: none;">
                <a rel="feedurl" href="', $scripturl, '?action=.xml;type=webslice">', $txt['subscribe_webslice'], '</a>
            </div>';`

First div is a waste of space. So is the third, IMO. All it needs is: <div class="webslice" style="display: none;">', $context['forum_name_html_safe'], ' - ', $txt['recent_posts'], ' - <a rel="feedurl" href="', $scripturl, '?action=.xml;type=webslice">', $txt['subscribe_webslice'], '</a></div>';

If anyone ever wants visible presentation, just set the anchor to block display if they want it on a new line. Easy.

Will leave the discussion about stay or ditch for now. Got other stuff to do.

[StealthWombat]

Oh eff it. Scratch the above. Ok, all the crud was required for webslices as such. Nothing to do with Atom, just IE-only crud. I can see the sense of keeping Atom feeds. No argument there. Webslices are another matter.

I'm totally over supporting IE-only crud when there are plenty of better formats around. Webslices may be based on Atom, but it's not Atom, and only IE uses it. I'd defo prefer to dump webslices. IE can still use Atom or RSS anyway.

[norv]

hslice, entry-title, entry-content, are part of webslices specification. (link). It appears to be supported currently by IE and Firefox addons, with some rumor or attempt from Opera 10 which apparently changed it to something similar but Opera-specific in the end.

I don't see why 4 lines of code in board index are harming anything. It initially surprised me that it was on board index (thought it was a bug, oops), but it's obvious since it's wrapping the recent posts fragment of that page. Sorry about that. Support for open formats for sharing data is a worthy goal (as these formats are, and while they've been blooming, some will be more used than others), and 4 lines of code isn't interfering with anything. It isn't about IE, it's about those users of IE (and Firefox) who would eventually see their favorite icon popping up and have a chance to use it. If it works, anyway. No admins will run around to look for addons insisting to "support webslices", the software is doing it. An example on them webs.

The microformats like this, html-based, require only to add their predefined semantic classes to the markup. ("what comes after hslice can be parsed as webslice"). Like hCard. Not to learn and implement a whole new language or protocol. That makes them bits of semantic data easier to support.

The rest of implementation is quite separate, so it doesn't make the rest of the code harder to read nor introduce bugs nor anything. Could be even more separate I guess. (in News controller it's barely starting up).

The latest years, much more open formats are more useful to people. It's worth learning about them and add more popular and new ones. But it's not like we have dozens yet. ;) I think open specifications are worth supporting as long as they don't really harm anything, or it's not too difficult. When we will have them dozens, we can reconsider if it's too much to support by default less used or older formats.

[StealthWombat]

Ok, I'll just leave it the way it was, and refrain from killing divs. :D

[Spuds]

If we choose to support, thats fine, but support should not be a hidden, un documented and un managed admin feature that we "stumbled" upon in the code ... Just sayin ...

[norv]

It's not an admin feature, it's available in the html output for anyone browsing board index, just the non-supporting browsers don't care. I documented the existing pieces, and added a note in the wiki; the latter probably needs a better place and wording.

[IchBin]

I'd prefer we remove something that's not not used and not a well known or popular technology that people use.

[StealthWombat]

Closing this one, since it seems to be decided.