0 users online. Create an account or sign in to join them.Users

Search

It's been a while since I posted here but came across this recently.

http://mobile.smashingmagazine.com/2014/02/06/applying-xsl-transformations-to-responsive-web-design/

Your thoughts?

It's very sad that many developers automatically take a shitty attitude to xslt, like sheep they all follow each other around on that.

Xslt is the single most powerful thing I've learned in web development in all of the years I've been doing this stuff. Sure it's complicated to learn, but I see too many 'easy routes' in the industry these days, all ending up making a mess of everything.

It saddens me that a large tech giant like Google can't see past this shitty attitude too.

Most of the responses to that article completely miss the main point of using XSLT in relation to re-flowing content as a way of achieving responsive design, which as far as I can see makes great sense if you're not in a position to rebuild a large site to be responsive from the ground up.

I get the impression that these people found XSLT hard/didn't spend long enough adapting their thinking to it and never became able to properly structure their templates, deciding to permanently blame XSLT for that, trotting out the "verbose" card.

I'll try and formulate some kind of useful comment to post there sometime, though I still count myself very much as an XSLT beginner. I reckon the comments section there (and the Blink dev groups post proposing removal of XSLT) could do with some input from Symphony devs.

and the Blink dev groups post proposing removal of XSLT) could do with some input from Symphony devs

How does this affect us? As mentioned in the proposal, this is about client side XSL transformation.

XSLT is more often used on the server as part of an XML processing pipeline. Server-side XSLT processing will not be affected by deprecating and removing XSLT support in Blink.

I mentioned the Blink XSLT removal discussion because XSLT being removed from Chrome won't do usage of XML and XSLT any favours in general. Serving browsers XML from Symphony is also (currently) an option, of course.

I was lured into the comments but I'm going to stay out of it now. It's clear that there are many misconceptions about XSLT that aren't going to change anytime soon, sadly. XSLT needs a rebrand :p

Brendan, I think the Symphony community has to step into this discussion somehow. I don't think the comments are the right spot, but additional blog posts and articles are.

I agree with Nils, I think we ought to put some effort to rectify this. With Symphony as is, the more negativity and misconceptions that surround XSLT the less likely are people to try using Symphony.

XSLT needs a rebrand :p

Actually, I think the concept needs to evolve. Think of something like "HSLT" (Hypertext Stylesheet Language) or "HTML5 Transformations" – something that gives frontend developers a better context, creating a tie between two worlds:

XML and XSLT for programmers – HTML, CSS and JS for webdesigners.
(Don't ask me why, but that's the common separation.)

It saddens me that a large tech giant like Google can't see past this shitty attitude too.

Google don't even add the (semantically correct) self-closing slash on code they provide. I've always assumed this is because they hate people that use XSLT.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details