Look, it's another Hyatt! Just goes to show you that Hyatt geeks are everywhere. Andy writes:
Just a quick note - there are basically two different ethnicities that have the name Hyatt. The one I belong to are Jews. Hyatt is a slight corruption of the Hebrew word for "tailor". The other are Scottish, and I'm not sure what their story is. Due to the Scottish immigration to the South, there are many Hyatts there.
I am of the Scottish variety, although I probably shouldn't have said anything, since this blog entry will undoubtedly lead to many jokes from Blake about kilts and sheep. Hopefully Ben will continue to corner the market on being the butt of sheep jokes.
Zeldman writes about a Safari bug in his blog. I investigated the problem and have it fixed.
For those who want to add to a list of known issues, the problem is that Safari collapses margins through bottom borders (oops). This means an example like this:
<div style="border-bottom:1px solid black">
<p>Foo</p>
</div>
will put a bottom margin outside the div! Again, oops. The fix has been made.
I just read Jason Kottke's article suggesting that Sherlock and Safari merge. Yes, I know, the rest of you probably read it two weeks ago, but, hey, do you want me spending all my time reading blogs or should I fix some Safari bugs every now and then? ;) Anyway, I also read John Gruber's rebuttal on Daring Fireball.
After thinking about the RSS issue in previous blogs it seems that applications like Watson and Sherlock provide a similar service for the Web that RSS does. Again, just like NetNewsWire, they present information to you in a more streamlined fashion, and again, you only fall into the browser when your interest is piqued (or in the case of some of the services, when it's time to buy).
Moreover in the case of some of these streamlined services, unlike news/blog feeds, some of these actually do feel "geekier" to me than the corresponding user interface you might have been presented with had you just gone to the Web site directly.
I wouldn't mind discussing how to tightly integrate applications like NetNewsWire and Sherlock with browsers, but at this point I think both should remain separate applications.
I had heard people mention the idea of using XHTML over RSS as a syndication format, thus allowing you to just use your blog home page as your syndication file should you choose to. Of course again that clashes with the idea of wanting to include only excerpts in your syndication file, and so it seems like this would be a bad idea, but don't take my word for it. Mark does an excellent job of debunking the idea of using XHTML in his blog.
One really good point several people brought up in response to my previous blog about RSS and Web browsers was that many feeds contain only article excerpts.
In other words RSS feeds seem to break down into two categories: feeds that contain only short excerpts of articles and feeds that contain entire articles. It does seem like integration makes less sense if the majority of feeds fall into the first category.
Then the RSS aggregator becomes useful as a filtering mechanism, with the Web browser being used only to view the articles that you ultimately decide to read. In this mode it seems like HTML display is hardly even a requirement for the aggregator application, since you basically just want to speed-read the excerpts from the RSS file and only go into the full blog if you decide that it's worth following up on.
Of course if RSS is going to contain the full blog entry, or if XHTML ever became popular as a syndication format (thus inspiring people to just use their blog pages as their syndication files as well), then some of the things that I said in my previous blog might hold true.
Hmmm. People seem to be associating Apple with various forces of darkness lately.
Crazy Apple Rumors
Blake's Blog
Let's see. There was MozClassic, then Mozilla, then Chimera, then m/b, which later became Phoenix, and now Safari. Dave Hyatt sure has a talent for starting browser projects, and then leaving. I think if you were to add them all up, Hyatt has probably worked on more web browsers than Blake is years old...
We've established that Blake is 8 years old, and I've worked on Web browsers for about 6 years, so... not quite. :)
For the record, the only browser project on the list above that I was in on from the beginning was Chimera. Well, ok, Mozilla too, but you can hardly credit me for starting Mozilla. :)
m/b was started by Blake and later grew into Phoenix. I in fact never worked on m/b (I don't believe I made a single checkin to m/b), and I didn't start work on Phoenix until after Blake had done an immense amount of work stripping down Mozilla and getting the thing building.
As for the assertion that I left browser projects behind, well, let's look at my track record:
(1) MozClassic - killed by Netscape. Didn't have much choice.
(2) Mozilla - stuck it out from the release of the source all the way through to 1.0 (which is way more than many others did). I'd say 4 years of my life spent working on Mozilla constitutes sufficient commitment on my part. Am I supposed to keep working on Mozilla until 2020? :)
(3) Chimera - Ok, I'll give you this one, but my reasons for leaving Chimera should be obvious by now.
(4) m/b - Didn't work on it.
(5) Phoenix - I am still committed to Phoenix. I haven't had as much free time as before, with the release of the Safari beta at MacWorld to worry about, but I hope to get back to it soon. While I will probably stop working on Phoenix when it hits 1.0, I am planning on helping it to become a complete product. Long-term I'm hoping that Phoenix can be handed off to some talented people in the Mozilla community who can ensure it has a future beyond a 1.0 release.
I thoroughly enjoyed American Idol last night, but Becca and I found ourselves wondering just how the contestants are screened. Simon, Paula and Randy obviously couldn't have seen 11,000 people in LA or 9,000 people in New York, so there has to be a screening process in place to weed out most of the people before they get to the judges.
What's interesting about this, if you stop and think about it for a moment, is that truly horrible singers are being deliberately let through to face the real judges, just so that we can listen to the triumvirate rip them to pieces. Talk about calculated cruelty. Of course it's also really hilarious. Can these people not hear how bad they sound?
You have to appreciate the irony when these truly atrocious singers are belting out lyrics like the following:
"If I fail, if I succeed, you can't take away my dignity..." (No, but we don't really need to, do we? You're doing a fine job of taking it away from yourself.)
"Fame! People will see me and cry..." (Or run away screaming, "The Horror! The Horror!")
"I'm bad, so bad..." (Hey, you said it. Now, for the love of God, stop singing!)
Blake Ross writes about his new splash screen manager for Mozilla:
To that end, I have graciously and without pay designed a solution that caters to everyone. I proudly present the splash screen manager.
You know, this is an excellent idea. I still think Mozilla needs a Manager Manager to manage all of its various managers, so that you can decide which managers should be actively managing and which should be turned off (i.e., not managing).
Unfortunately, I don't think this whole splash screen manager idea will work for Safari. You see, oddly enough, we made it a priority to start up virtually instantly, which makes a splash screen somewhat pointless.
I know! It's clearly time to implement the Startup Delay Manager for Safari. The entire browser can launch with a randomized delay, or maybe it could slide in from the side of the screen, or it could dance its way out of your dock while singing "Getting to Know You."
Clearly this is something people want, so we'll make it a priority. After all, the users come first.
I have spent today playing with a piece of software called NetNewsWire. It's simply wonderful. I had used FeedReader before on Windows, but now I have a fantastic Cocoa application that can handle aggregated news feeds. And it's zippy too! Kudos to Ranchero Software.
NetNewsWire even displays HTML somewhat (if you include it in your RSS feed). I wonder what it uses to do that (the old HTML display component or its own home-brewed component).
Regardless, I smell a future customer... :)
NetNewsWire + Safari WebKit = Ass-Kicking Goodness.
I wonder who I have to sleep with to get into the default subscription list. Maybe I need to stop blogging about the technical guts of Safari and start seeding my blog with catch phrases like "Kate Bosworth Naked."
As if I needed any further proof that scorpions were evil, from CNN comes this little gem.
I hopped over to Blake's blog, and for the first time since November, there are possible signs of life! Instead of the usual stale blog entries, there is now an image of "blakeross.com".
Sure, so it looks like someone played with too many visual effects in PhotoShop, but if it means a return to the blogging world for Blake, who cares if it's pretty or not? Could this title graphic herald the impending return of everyone's favorite 8-year-old to the blogging scene? Stay tuned.
Turns out Eric Meyer's Pure CSS Popups demos didn't work quite right after all. Oh, sure, I fixed the :hover effects so that stuff actually started showing up, but oh my was it not laying out correctly.
The bug turned out to be another one of those frighteningly basic ones. I was mightily embarrassed when I found it. Positioned and floating elements inside blocks with inline children were actually being added to the line. So basically all positioning was busted if you put a positioned element inside a block with inline children.
It's all better now though (crosses fingers).
I spent all day today reworking :hover in Safari. I fixed the repainting problems that exist in v51 when using :hover with positioned elements. I also now have Safari working flawlessly with Eric Meyer's Pure CSS Menus. I haven't tested them yet, but I'm fairly certain that Safari will also now work with his Pure CSS Popups demos as well.
I've added an alternate stylesheet to this blog called "Rust". If you're using Safari, you'll notice that the blog goes off the deep end when you switch to the sheet. That's because some elements become positioned in the alternate theme that weren't positioned in the default theme, and Safari can't handle dynamic position changes in v51. Don't worry, though, I've fixed the problem in the main tree. Yes, it was my fault that this didn't work (again). It probably works in Konqueror. :)
I landed the new table code from the KHTML trunk in WebCore today. Meanwhile Lars is working on a new CSS parser on the KHTML trunk that we'll be taking back into Safari once it's baked a bit longer. Now that the table code has been put to bed, I'm planning to work on the inline box model issues that plague Safari.
The only problem is I can't seem to figure out how the inline box model is supposed to work. It looks like Gecko added a whole new mode called "almost standards" mode just to deal with line-height calculations in a different way. As if two modes (quirks and standards) weren't enough, now we have to have three.
Sometimes it's hard being a browser implementor, because these standards are constantly evolving, the language is changing from version to version, and you can't just stare at an older specification and know reliably what you're supposed to do. Add to that all the behavior that is still under debate or under-specified (such as z-index and clipping behavior), and it can just make you want to beat your head against your keyboard in frustration.
On the plus side, at least I figured out why floats with margins weren't painting. That was a nice little 1-line fix. The bug was, as many bugs are, my fault. :)
I keep receiving emails from people trying to build applications using WebCore. People are asking me for help or advice on implementing the bridge inside WebCore.
I don't know why people are trying to do this. It should be obvious from looking at the code that WebCore and JavascriptCore are incomplete, and that there are other pieces required in order to build an application around the Safari engine.
If you're trying to embed the Safari layout engine right now, stop it! :) Don't try to build code around these two components.
Update:: Quoted from ADC: "In addition to providing the best web browser for Mac users, one of the goals of Safari is to provide a fast and efficient HTML rendering engine for Mac application developers. Apple is actively
preparing a Safari SDK that will be available later this year."
In other words, all good things come to those who wait, so be patient! :)
Mike Shaver and Chris Blizzard respond to Paul Festa's anti-Mozilla ranting on news.com. Just goes to show you, boys, you have to be careful what you say in your blogs, since you never know when someone is going to come along and quote you out of context in order to satisfy some obsessive need to bash Mozilla.
In the "Did you know Safari could do this?" category comes the following tip. Safari supports an extension for examining the preferred stylesheet set and for setting the current active stylesheet set, so if you want to swap between sets of sheets in Safari, you don't have to loop over all of them setting the disabled property. You can get and set the selected set using an extension on DocumentStyle called selectedStylesheetSet. You can examine the preferred set through preferredStylesheetSet.
document.selectedStylesheetSet = 'alternate1';
We now have XML limping along in Safari. We are treating application/xhtml+xml, application/xml and text/xml as XML files and sending them into the XML parser (expat). If there's any other MIME type we should be supporting, let us know. Now that we can finally see XML, we have to update it to deal with other fixes we made to the KHTML engine, like making XML processing instructions that load stylesheets delay render object construction (to avoid the flash of unstyled content you'd see otherwise), and to fix our XML component so that it doesn't eat whitespace (so that preformatted text will work in XML).
I've just finished merging KHTML's new table code (over in the KDE tree) back into Safari. It fixes a lot of bugs with auto layout tables, especially the way extra width is distributed among cells. Yes, Ben, it fixes your blog. Yes, Joe, it fixes yours too. The new code also supports fixed table layout, so the eight of you out there that actually use fixed tables can now rejoice. ;)
Mark writes that he has discovered a way to hide CSS from Safari. He's called it the Safari Spacer Hack. While it's neat that people finally found a bug in the parser that afflicts only Safari, it's just that: a bug, and relying on these bugs in what should be a standards compliant parser is wrong.
Here is a proposal for a way to include Safari-only CSS:
@-konq-only { .... }
Here is a proposal for a way to hide CSS from Safari:
@-konq-end;
The former would be a special block (similar to @-konq-quirks for quirks mode rules in UA sheets) that other browsers would ideally ignore. The implementation of this feature would naturally depend on other browsers ignoring @ directives that they don't understand. Can anyone confirm this?
The second idea, @-konq-end, would be used within a style block or within an external stylesheet to signal the end of the sheet to Safari. It would then ignore anything that followed @konq-end;.
Thoughts?
In response to comments made on Jan 8 on memeufacture.com about the site misrendering. I've narrowed it down to a basic fundamental problem. Whenever text can't fit on a line with a float, KHTML (Safari's version at least, maybe this has been fixed in Konq) shoves the text down past *all* floats. In memeufacture's case there is a horizontal float stripe across the top and another vertical float stripe down the side. What's happening is that rather than just placing the objects right below the horizontal float stripe, the text is being shoved all the way past the vertical stripe as well.
I've filed a bug. This probably affects a fair number of weblog sites (you guys love your floats), so I'll try to address it soon.
Before sending email, please be aware that I'm not going to comment on future Safari releases (i.e., when they will be, what they will be called, etc.). I am also not going to comment on questions about when particular UI features are going to be implemented, so please - for the love of God - stop asking me if/when UI feature "X" is going to be implemented in Safari.
In Should Safari be intentionally buggy?, Mark brings up the need to have a way to hide CSS from Safari. However all of the suggestions that I see involve ways to include Safari-only CSS, which seems to be the opposite goal. I suppose people want both. I'm certainly open to the idea of a special way of indicating Safari-only CSS, as long as it is in no danger of violating standards and can be done in a reasonable fashion. It seems like finding a way to hide CSS from Safari is more problematic, and it also seems like this would be the more common case.
By the way, Mark, your blog is now fixed in Safari (this is problem #2 on your list). Those who care can bring up khtml/css/html4.css in WebCore and move the -konq-flow-mode properties in the rules for UL, OL, MENU, and DIR into the quirks block at the bottom of the stylesheet.
FWIW, we have also addressed problem #3 and #5-#7 (this was a bug in our image renderer and is not a bug in KHTML), which means #1-#3 and #5-#7 have all been fixed. You keep filing, we'll keep fixing. :)
Blogger Pro blocks Safari. I wonder what UA check they do. It must be more sophisticated than simply looking for the word "Gecko" in the user agent string. Blogger, if you're listening, you can treat us just like Mozilla. We will work. What do you think I used to post blogs on the Mac before you started blocking it? :)
I started looking into these CSS issues today. The first issue on Mark's list is that outside list bullets inside an li with text-align: right (either explicitly specified or inherited) are not positioned next to the text content. I think we're off to a good start, because I believe that Safari is not only correct on this test case, but that every other browser is rendering that page incorrectly.
I refer you to paragraph 7 of section 12.6.1 of the CSS2 spec. Essentially since the bullet should be positioned relative to the line box, text-align is not going to have any effect on its position. It will be just outside the line box. To achieve the rendering effect you desire, you should just set list-style-position to inside.
[Update: Boris Zbarsky informed me that the language I referred to is no longer present in CSS2.1. Thus the positioning is now ambiguous, so it's sort of left up to the browsers to decide how to position. I will, however, note that the CSS3 Lists draft does clarify this situation in favor of Safari's interpretation.]
On to issue #2, which is much more obviously a bug. :)
The issue with VersionTracker's front page has been addressed. The page is actually malformed, and we had to improve our error handling code to deal with the malformation. (A stray div wrapping random table cells inside a table.) Note that this was not a bug in Konqueror but was a regression in Safari only.
A number of people have commented on Safari's UA string, which is as follows:
Netscape 5.0 Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48
The portion of the UA string that seems to be stirring up controversy is the portion that says (like Gecko). The reason it is there is that in order to work with real-world DHTML sites you have essentially two options: you can claim to be MSIE or you can claim to be Gecko. We found that any other choice that we tried led to a significant portion of DHTML malfunctioning. You would not believe (well, maybe you would) how much DHTML exists out there that works only with MSIE or Gecko, and that uses proprietary extensions of each to accomplish the DHTML effects.
Had we released a browser with a UA string that did not superficially match either MSIE or Gecko, users would have downloaded Safari and experienced many malfunctioning Web sites. If anyone thinks that would have been a good idea, please step forward in your blog and explain why. I'm willing to listen.
Our solution was a compromise. We produced a user agent string that is different from Gecko's and easily distinguishable if you choose to sniff for it, but that at this time will pass most UA checks that sniff for Gecko. It may be that enough sites will start sniffing directly for our string that we can drop the "(like Gecko)" from our user agent string, but I'm not optimistic.
We chose to be more like Gecko than like MSIE because we wanted to be lumped into the standards compliant category, because fundamentally we are committed to supporting DOM 1&2, CSS1&2, and enough proprietary MSIE extensions and Gecko extensions (innerHTML, createContextualFragment, offsetWidth/Height, etc.) that we could be placed in a similar category.
That's all from my end. I welcome constructive feedback on this issue.
As reported on numerous blogs, Safari can't run the CSS1 test suite. This had to do with missing support for <object type="text/html">. We have fixed this issue and are now able to run through the suite. Thanks to the many bloggers who pointed out the problem.
Various members of the Flash community have been reporting low frame rates when using Flash in Safari. I'm pleased to report that we have corrected the problem. The issue was not in WebCore, so I can't post a patch, but the issue has been addressed.
You can check out this article on Slashdot that outlines one approach. I'll just add that if you want to avoid copying the frameworks, you can set DYLD_FRAMEWORK_PATH instead, and then you can leave Safari.app alone. Thanks for saving me some time by writing this article! :)
Just a little update to let you know that we have Safari working at 96dpi now.
Eric Meyer writes in his blog:
Meanwhile, I've heard credible rumors that Apple, while it was working on Safari, filed Bugzilla evangelism bugs so that the Standards Evangelists at Netscape (of which I'm one) would get the sites to fix their code to work with Gecko and other standards-compliant browsers. This would then, they apparently hoped, get the sites working in Safari as well. If this turns out to be true, I'm going to be furious; just the idea that it could be true makes me angry. I don't mind helping out Apple. I'm a Macintosh guy and have been for more than a decade now. I do mind being tricked into doing their work for them. Hey, guys, what's wrong with saying, "We're both working on standards-based browsers, so let's work together to get sites to support standards?" You know, being honest? How about that? Anyone think of that?
This is a ludicrous claim and is completely without merit. I challenge you to either retract this statement or back it up with hard facts. As far as I know, I am the only member of the Safari team to have ever filed a bug on the evangelism component in Bugzilla, and the only bugs I can think of that I did file were discovered while using Phoenix or Mozilla. As an example, I pointed out wsj.com's broken "Netscape6" check in the user agent and filed an evangelism bug. I still develop for Phoenix and use it on Windows. Should I avoid filing bugs on Mozilla that if fixed will make Gecko work with more Web sites simply because my email address ends in "apple.com"?
Scott Andrew writes in his blog:
Word is trickling in about the new Apple browser called Safari, which was apparently announced at Steve Jobs' keynote at MacWorld SF. The rendering engine is built on something called KHTML, which may be the KDE library of the same name. Apparently built for speed, the Apple page boasts of support for XHTML, DOM, JavaScript and Unicode, but provides no details as to the level of support (according to the docs, KHTML itself only supports DOM Level 1 and CSS 1, so I don't hold out much hope) for these technologies.
KHTML supports much of DOM level 2 and CSS2, including the DOM level 2 event model (e.g., mutation events too!) and rich selector syntax (even a little bit of CSS3 selectors). In addition we have added and fixed CSS support in a number of key areas, including partial support for min/max-width, better support for z-index (including support for auto z-indices), and better support for the CSS white-space property.
A patch has been posted to address issues with visual Hebrew support. We are examining the patch (especially since it involves Apple-specific #ifdefs), so stay tuned for more details. The patch is here.
I will be providing instructions shortly for how to run a modified Safari with WebCore or JavascriptCore changes, so watch this space.
I will be responding to other bloggers' comments on Safari as I discover them. This first response is to some of the comments raised on diveintomark.org.
Initial attempt to load my home page failed; it downloaded the page instead. The user-agent sent by the browser is Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48; my server is picking up on the word "Gecko" and assuming this is a Mozilla derivative, and sending my site with a MIME type of application/xhtml+xml, which Safari apparently can not handle. I’ve fixed the error on my end, but if this has already happened to you, you will need to empty your cache (under the "Safari" menu) and try again.
XML support (sent as one of the XML MIME types) is not present yet in Safari, since the Qt component used for XML parsing has not been ported yet. This means that XHTML1.0 will work as tag soup (if you send it as text/html like wired.com does), but true XML support is not there yet in the beta.
My home page now renders, but only partially. None of the links on my navigation bar show up. Konqueror is the only other browser that exhibits this behavior. (This makes sense, since the two browsers are based on the same rendering engine, KHTML.) This was the one known bug I decided to ignore in my redesign six months ago. Guess it’s time to finally work around it.
Narrow it down to the smallest possible HTML snippet, and send me the source (hyatt@apple.com). I'll take a look.
According to Matthew Haughey, Safari defaults to 72dpi rendering of type, instead of 96dpi. All other modern browsers on all platforms default to 96dpi. This means that any site that uses relative font sizes (or no font sizes) will display 25% smaller in Safari than in any other browser. (Mac users had this problem 5 years ago, when Netscape 4 defaulted to 72dpi rendering, and fonts were displayed 25% smaller than IE 4 for Windows.)
I believe that Chimera does not use 96 DPI, and that our rendering, although unlike Gecko and IE on Windows, is actually fairly similar to Chimera in this regard. At the moment we are using 72 DPI, although much of that decision has to do with problems we're wrestling with over Cocoa NSFonts handling DPI for you (internally), which meant that at 96 DPI, we had larger errors between "px" and "pt" sizes. In order to simulate 96 DPI correctly, we will have to apply a correction ourselves.
It's out. Download it here. Yes, I am a member of the Safari team at Apple. I work primarily on the WebCore, the open source portion of Safari that contains KHTML (as well as the implementation of the Qt subset required to support KHTML). In future blogs I'll be talking about some of the changes and architectural improvements that we made to KHTML and explain those in more detail, but for now I'm going to get some much-needed sleep. :)
For a few days now I've been monitoring a thread on www-style started by Shelby Moore that is critical of XBL. The thread began in December and has spilled over into the New Year. It mostly seems to be a back-and-forth between Shelby and Ian Hickson in which Ian has made some really good points.
The essential criticism of XBL (if I understand Shelby correctly) is that it can change the semantics of a given tag. I'm not convinced all parties even agree on the definition of semantics, nor do they seem to agree what semantics are implicit in a tag before a user agent (i.e., a browser) has even decided how to render the aforementioned tag.
I am of the opinion that tags in a given language do have semantics, meaning that is imparted to those tags by the specification for the particular language to which the tags belong. For example, a <select> element clearly has a certain meaning as outlined in the HTML specification. The presentation of the element, however, is left up to the user agent.
This is where XBL comes in. There are any number of ways in which a select element could be represented, and using only CSS you have a rather limited range of options. Using Ian's example from the mailing list you might want to present a select of countries as an interactive world map, with countries highlighting as you roll over them. This kind of complex presentation is beyond the scope of CSS, but it is not beyond the scope of XBL.
Rich presentations are made possible using XBL without altering the meaning of the original element. The original DOM is left alone, and the element can be manipulated by the source document without the attached binding being even remotely relevant to that source document. XBL therefore resides at the same layer as CSS, capable of dramatically controlling the presentation of an element but not of altering the underlying semantics of that element.
As another example, consider a heading element in XHTML2, e.g., <h>. The semantics of such an element are clear: it is intended to be the header of a particular document section. However, there are any number of complex presentations that one could imagine for such a header. Perhaps the author wants the header to fade in. The author might want headers to scroll in from the left side of the browser window. Maybe the author wants to offer an interactive menu on headers that shows the other headers in the document and lets you jump to them. All of these choices are presentational and in no way alter the semantics of the original element.
Another example is Andrew Wooldridge's Flash chrome, in which toolbars and buttons in XUL were represented using Flash. One could envision using SVG in a similar fashion with XUL. Again, the semantics of XUL remain unchanged. A button is still a button. A toolbar is still a toolbar. Is it possible to make some ridiculous presentation for a button that makes it look completely unlike a button? Sure, but you could do that using pure CSS, without involving XBL at all. Regardless of how you present the button, you still haven't changed the semantics of the element itself. The XUL source document will still see a toolbar containing button items. The semantics remain unchanged.
So of course it is possible to choose a poor presentation that may obfuscate the original semantics of the element as far as the human eye is concerned, but that does not mean that the underlying meaning of the element has been altered by XBL. It simply isn't being communicated effectively to the end user because of poor presentation. CSS can be used to compromise the rendering of elements as well. It still isn't affecting the semantics of those elements.
I view the effect XBL can have on an element as no more radical than (for example) the CSS display property. Using that property, you can represent a list item as a table cell or turn a span into a table. The meanings of those tags remain unchanged. As far as the source document is concerned, an <li> tag is always a list item, regardless of how it is presented.
This is my position on XBL, that it augments CSS by enabling arbitrary presentations to be applied to tags. It exists in the same layer as CSS, and has no more of an effect on tag semantics than CSS does.
