Subject: Re: [xsl] XSLT vs Web Components From: "Matthew L. Avizinis matt@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Fri, 12 Sep 2014 17:00:53 -0000 |
I appreciate all the responses. quite informative as usual. I was just curious to get a few opinions because encountering a problem, then finding a solution sometimes involves deciding between a tried and true method which might be more difficult but likely to be around a while, or taking a leap of faith that a new method will catch on fire, for instance the way node.js, nosql, and json has for a certain class of problems. xml and xslt has been a good solution for my employer for a decade now and I'm glad I went that route, but personally I was disappointed (yes, I got over that a some time ago and moved on) that xslt didn't take hold more with browser developers. Regards, /Matthew L. Avizinis/ Gleim Publications, Inc <http://www.gleim.com> On 9/11/2014 4:35 PM, Mark Giffin m1879@xxxxxxxxxxxxx wrote: > On 9/11/14 7:46 AM, Matthew L. Avizinis matt@xxxxxxxxx wrote: >> One of the primary uses of XSLT is transforming xml to html, it seems >> like. I don't have data handy, but based on what I've read on this >> list over the past dozen years or so, seems like a reasonable enough >> conclusion. >> I've recently been reading about X-Tags, Polyfil, Web Components, >> etc., and tinkering with it. (for instance, x-tags.org, >> webcomponents.org, and >> https://developer.mozilla.org/en-US/Apps/Tools_and_frameworks/x-tags). >> It seems like pretty cool stuff and it occurs to me that by using it >> one could pretty much eliminate the use of xslt for such >> transformation, if I understand it correctly. > I can see a lot of uses for them, but I'm having trouble imagining how > web components would eliminate the use of XSLT. Can you explain more > what you mean? They are not presented as a transformation language. > They're actually presented as a browser-native way to do UI widgets > that are easy to share and use for web apps. This is where I could be out of my depth at this point because I haven't had nearly as much experience with it yet like I've with xslt. Having said that, I was thinking along the lines of what J. Kosek mentioned in his reply and I was currently thinking only in regard to web browsers. It seems custom elements in a given schema could be defined to present a particular way without the need to transform them. Of course, the data might need to be filtered first which might require a xslt transform, but getting it finally to the browser seems like it would be simpler. > >> 1) Do you think the web components concept will catch on widely? > Yes most likely in my opinion. >> 2) will they be supported by browser developers natively >> eventually, do you suppose? > They already are supported in Google Chrome and Firefox Nightly (you > have to enable a flag). You don't need polyfills in these two browsers > that I have seen after working with them a bit. > > Mark Giffin > > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <-list/650101> > (by email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT vs Web Components, Mark Giffin m1879@xx | Thread | Re: [xsl] XSLT vs Web Components, Jirka Kosek jirka@xx |
Re: [xsl] process xslt and xml spre, Tony Graham tgraham@ | Date | [xsl] Getting text and non-block no, Eliot Kimber ekimber |
Month |