Wow! This seems so true, it never occurred to me how inefficient it was re-rendering each version using XSLT compared to XBL. I can see how XBL is more suitable in the 'Browser space', although XSLT would have less of a disadvantage in other applications where multiple themes and dynamic content are not an issue.

Too bad MS will probably never support XBL...

Let's comment on this from a XSLT peer point of view.

Basically, the analysis is right. I am one of the most current "implement this in XBL and not in XSLT" folks. The real benefits of XBL are that it is *live* and keeps the original document.

I don't think that the analysis of the additional styling step is really true, though. XSLT is designed to be used on real XML. It's not really meant to be used for stuff like rss, which is XML wallpaper around the html content. XSLT has its great strength in transforming the actual data into a (potentially very different) tree. Thus the usual result will take textnodes from the source, but no markup elements. Additionally, the "anonymous content" will likely be outnumbering the "copied content". Thus hardly any CSS styling would apply to result elements copied from the source document.

One thing that XBL can't do are things like table of contents or other constructs referencing content from the source in distinct places. The ability of XSLT to generate those make it (more or less) impossible to make XSLT transforms live, though.

So, there are good reasons to use XBL, but there are some good uses for XSLT, too. Not just implementation, but also features.

Good points. I should have mentioned that XBL's adornment capabilities are quite constrained and so if the author needs a really radical transformation, XBL could well fall short.

XSLT can definitely achieve a wide range of complex transformations that cannot be matched by XBL. XBL is good when the transformations can be represented purely as adornments.

I think one of the best arguments you made is that the resultant XSLTed document still will (or should) usually require further CSS processing. I've often thought about how one would go about using XSLT, especially from the point of view of re-designing some styling or another. I kept coming to the same conclusion that using XSLT alone would often require just as much work to implement design changes as good old tag soup would, so the time savings benefits are largely lost. More and more I've decided that using XSLT for display purposes (as opposed to data exchange) is best limited to reshaping raw XML into a more CSS friendly format so that you can maintain clean raw code, hack-free CSS and still implement ambitous design ideas.

Apples and oranges, but what happens when you try to do things with them IRL... As is pointed out, XSLT is available in IE while XBL isn't... forget about XBL then, unless you want to send different files to different browsers, but since you have to have more or less the same design for other browsers that's just double work for more or less nothing... XSLT is OTOH best used on the server if you want to reach most visitors...

The most "advanced" thing you can do without scaring some visitors away ends up being XHTML, and due to bugs etc you can't even use all the CSS that you "should" be able to use.

To most people this translates to: "Why even bother learning what XSLT and XBL and [whatever] is when you can't even use it?"
Heck, it's even close to impossible to get people to learn proper (X)HTML as long as they know that they can trial-n-error their way towards a "design" that works in IE.

Soo... who are going to use all these fancy new features in webbrowsers... no one but bloggers? :-D

Thanks for arguing for things from a technical perspective, but also noting the current practical situation.

If we didn't have people like you pushing on the technical front, the technology would never move forward. On the other hand, it's by engaging with the way things are now (with the IE status quo) that the practical situation can be improved.

Sorry if that's vague.:)

Couldn't you just support both in Safari? I have no idea of the work involved but it seems that Mac users would be best served by supporting the same protocols as the majority of internet users. It may be an inferior product but support should still be a priority.

Jon - 3 things:

1) It would be really cool if XSLT and XBL were supported in safari
2) It would probably be a lot of work to implement them in safari
3) The majority of net users DON'T have support for these. Well, IE supports XSLT, but only Mozilla supports XBL.

"In this imaginary world, the author has a choice to make: XSLT or XBL"

I think you could use both. XSLT is for transforming one tree into another (like XML to XHTML). CSS and XBL is for styling a tree.

With XSLT on the client (in win ie) you can change your XML or your XSLT dynamically (and independently) giving a new result tree, with a totally new structure (tags, data etc.). This is beneficial in, as an example, a stock watcher since you only have to retransmit the data.

I think these two technologies are very different in their goal. XML --> XSLT --> XHTML is for separating DATA and STRUCTURE. While XHTML + CSS/XBL is for separating STRUCTURE and PRESENTATION.

What I do all the time is have my own "proprietary" XML data, convert it into XHTML with XSLT and then style it with CSS/XBL.

I'm not sure of any of this %-)

neato burrito bug I found in Safari! Wonder if you've seen or heard of this one before.

I keep my browser open ALL the time (safari and camino). When I don't need them open, I just close all the windows and leave it there. This has happened before. I close all the windows, THEN I go on up to History and select clear history. IT DOESN'T CLEAR. But when I DO have a window open, it DOES clear... oddity no?

Mr. C

XSLT might not be as good as XBL at adorning a document, but XSLFO is!!!!

Just kidding.

Mm, I'm with Jonas: XSLT and XBL seem like complementary, rather than competing, technologies to me. Which is no bad thing.

I know nothing about XBL, but a great deal about XSLT, and I just want to "correctify" something in statement #2: When you use IE's clientside XSLT processor, the original XML source is preserved, and what you actually see, when inspecting the source.

And that is exactly one of the reasons why I use ServerSide transformation instead.

/CS

On thing to keep in mind is that although it's not possible to control what browser a user has in the wild, in some cases it can be done on corporate/academic networks. In this case, with XBL, XUL, the mysql/postgres database support etc, you can see the argument for Mozilla as a platform, where web-based applications can be handled from a server side location and sent out to clients, thereby avoiding software upgrades, etc.

I'm not saying it wouldn't be great to see these technologies supported in other products, just pointing out that they're not completely useless merely because gecko based browsers have small market shares.

XSLT is definitely useful for transforming XML source trees into multiple derivatives. I use it extensively to provide both XHTML and WML interfaces for mobile devices. The transformation happens on the server side (PHP + Sablotron) always on the fly. The speed is blinding on a moderately powered Linux box. The trick is definitely creating the XML source tree correctly. First I design the source tree keeping in mind what the resulting documents should look like---then creating the stylesheets is simple.

XBL competes with MS "behaviors", not XSLT

I'd just like to extend on Leechy's point. I keep seeing comments basically saying "IE has XSLT and Mozilla has XBL".

Firstly, IE has XSLT and "DHTML Behaviors" and/or "HTML Components":

http://msdn.microsoft.com/workshop/author/behaviors/overview.asp
http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp

I'm a bit rusty and can't remember the exact difference between the two. However, they are largely equivalent to XBL, even down to the way CSS is used to hook things up. This seems to have influenced BECSS, part of CSS3 that looks to have stalled:

http://www.w3.org/TR/becss

Secondly, Mozilla supports XSLT and to a pretty good standard too in my experience.

http://www.mozilla.org/projects/xslt/

I just noticed a possible font/color bug. I hope it's OK to post it here. Consider:

<ul>
<li> Not Red <font color="#ff0000">
<ul>
<li> This should be red. </font> </li>
</ul>
</li>
<li>But this should not be red, according to IE and Camino</li>
</ul>

This is an issue at the following real page:

http://twiki.org/cgi-bin/view/TWiki/TWikiPreferences

That code is crap and completely malformed. Bah. :)

I believe that Safari should be able to support XBL, the case made for it is compelling. I believe it would be a mistake to dismiss an important advancement in browser technology simply because IE does not support it. It is programmers in corporations that force adoption of technology, for the most part. If Safari on OS X and Mozilla on everything else are consistent in their support of XBL, then MSFT will either be forced to catch on or you will see more and more adoption of Safari and Mozilla.

There is pent up demand in the Windows developer world for a better browser and it appears that MSFT may not release anything significant till 2005. What developers need is a legitimant alternative with a compelling enough reason to move forward.

My point about the malformed code was that it might be nice (other things being equal) if Safari rendered it the same way IE and Gecko do. It's currently being distributed with TWiki, a widely used wiki variant. I'll file a bug report with the TWiki maintainers, but they average around a year between new releases.

If TWiki puts out garbage code, and they only test with two browsers, then their wiki should be ignored, widely used or not. They can go suck an egg (they already know how to suck).

-Walter

I belive both XBL and Microsoft's behaviors have been submitted to w3c. Wasn't there a raging debate recently about whether xbl was added anything that xslt couldn't do ....

I don't recall most of Dave's points in support of xbl.

btw xbl rocks like Elvis.

yes here
http://www.w3.org/TR/xbl/

Hi Dave,

may I first say that having cool new technology (like XBL) in Safari is always a plus, but Safari should first at least support CSS1 and 2 and DOM Level 1 and 2 to have a solid foundation for new things to come in Safari 1.x or 2.0, in my sort-of humble opinion.

Secondly, Safari v73 completely ignores the CSS clip property and does not support overflow:hidden at all. Also, I apply overflow:hidden to the body tag to prevent scrollbars from appearing at all even though content is extending over the right and bottom borders of the window.

I use this in a DHTML thingy that is a replacement for a Java applet -- which we can't use on the Mac as no Mac browser supports LiveConnect at all.. what is the deal with this anyway? Does Apple's VM just not support this or? -- and it is quite vital that clip and overflow:hidden are supported.

The scriptlet works on IE5Mac and Mozilla/Mac and Safari is the last one (it works fine except for the content leaking out its parent div and window).

Finally, can you tell us if Safari will have any script error notifications like Mozilla/IE/Opera? Safari currently just shoves everything under the rug. There is no Error object, onerror is not called, nothing. Opera 7 and Mozilla do it right by passing along a full stack trace with filenames and line numbers in the Error object when an exception is thrown. Are there plans to support such things in Safari?

Regards and thanks for your time,

Arthur Langereis

Oh, and window.onresize is not called ;)

Hey, Dave:

Saw this on VT, among the v74 posts. Thought that it might interest you.

Stuff wolfmanny
Version: 0.9, 5/15/2003 01:29PM PST
Go to vtext.com with any version of Safari, even the latest build out today. Attempt to enter text in the fields, "Your Message" "Reply to Address" and "Callback Number"...that's the only real problem I have with Safari..it would be nice to have the preferences available with Safari Enhancer built-in as well More Info

The is usually not overflowing when scrollbars appear on the _viewport_, so changing to overflow:hidden will generally not affect the viewport scrollbars in CSS-compliant UAs... unless they add some gross hacks to be like IE/Widnows, in which the and the viewport are synonymous (which leads to other bugs in its rendering).

Boris - I assume the 2 missing words were "document", right?

STYLE BUG - In Safari 1.0 Beta 2 (v74) - Back/Forward style missing/showing (and scrollbar fails)

In the page:

http://pixel.recoil.org/cocoa/unicodefontinfo.html

when you first visit, the page appears with no style. If you press the "Back" button, then the "Forward" button, you'll see the page with full style (a navigation pane on the left)... Not only that, but using the scrollbar now does not move the page, the content is static although the indicator moves up and down... If you hit "Reload" the style will disappear again. The "Activity" window does not mention any error, either before or after the style shows up.

?

The missing word was <body>

Browserwolf:

I went to vtext.com, and had no trouble at all.
What problem do you see? I type text, and it appears in the boxes just like on any other page.

-baffled boo

Oh, my JavaScript is turned off, per my personal preference.
JavaScript is evil.

-boo
Can you hear my text now? Can you hear my text now?

Ah, how I love one-shot provoking statements without any supporting arguments.

What a beautiful day this is going to be!

safari v74 is out, but no support for overflow: auto ... what happened??

Ryan - is it possible that he's not done with it? I saw posts about him working on it, but did he finish?

Maybe he did finish, but then again, maybe v74 was done before he was done with overflow:auto and they just decided to release it now, but the current internal version is higher?

I dunno, just conjecture

bummer :(

One way MS is going to support it is when it becomes a standard and some daring people start using it. MS won't disappoint a huge section of crowd.

I'm just a user for the most part. I've tried making websites before. Once when HTML 4.0 was so new that IE had yet to support CSS stylesheets, and then again using GoLIve6.0 for a project.

I'm just wondering, when, where, and why do people use all these things like XSLT, XBL, XML, DHTML, XHTML, DOM, ASP, PHP, etc. All the books I've seen in barnes an noble about them tend to be multi-hundred page texts that assume I already why I want to use it.

vincent,

Well I'll let others cover XBL since I never heard of it before reading these new threads here.

XML: For me, I use it as a data source. My server-side scripts insert data from XML files into HTML templates, and then serve the resulting documents to users.
XSLT is an XML-ish way (as opposed to a procedural way) to transform XML data into HTML or XHTML.
DOM and DHTML are client-side technologies requiring special browser support. DOM provides scripting access to the entire parsed tree of HTML elements in a document (usually only available via JavaScript), and DHTML is a fancy reference to using JavaScript to change the content of a page.
ASP and PHP (and Perl) are server-side technologies for serving dynamic (i.e., up-to-date or interactive) content, and do not require any special browser support -- they work in all browsers.

-Walter (a Perl dude who codes HTML by hand)

Oh, forgot to cover XHTML.

It's HTML shoehorned into XML restraints, designed purely to make the job of parsing easier and more efficient. It's meant for devices with limited memory (such as handheld or other tiny devices). It requires that all tags be in lower case, since XML is case sensitive and there was a 50:50 chance of your favorite case losing.

I stick to HTML for the following reasons:
* I prefer working with uppercase tags.
* I've never seen documented proof that XHTML is compatible with every version of every HTML browser on the planet.
* If I have content for a tiny device, I will design its "wrapper" accordingly (WML, cHTML, etc.), to save bandwidth and ensure usability.

-Walter

Has anyone seen the Simcity 4 web site? Safari renders this site completely usefulness. If one clicks one of the left side menus this causes the hole web page to be unresponsive to any click any were.

Sorry... I forgot the URL for the Simcity 4 web site that is http://simcity.ea.com/

Thankyou Walter :)

That helped me out a lot :)

"DOM and DHTML are client-side technologies"

You can also use the DOM on the serverside :-)

Dear Mr. Hyatt:

I've been submitting to Apple the following page:

http://www.liceo.edu.mx/

This page is from the local K-12 school where my relatives go to school. It includes a moving banner where the page checks a local database and puts the kids names the day its their birthday.
It used to work before v74, now it crashes Safari every single time. Can you please fix this? I did send the page, source and everything to Apple to no avail.

I do not know ANYTHING about programming, I just know that the page invariably crashes Safari when it didn't use to.

Please help!

It crashes my Safari v74 as well. In addition, though I haven't been able to isolate it, this build is crashing more often. With me it seems to be related to Java Apps, such as Ameritrade.com's streamer app. It is sporadic, but there seems to be a connection. Sorry I haven't been able to narrow it down further yet.

"You can also use the DOM on the serverside :-)"

Well don't just leave me hanging there! <g>

Got URLs?

thanks,
-Walter