My 5 year old can play World of Warcraft. I don't think I've ever hear anyone blathering about "intuitive" or "simple" controls who knew what the fuck they were talking about.
The page as currently shown has no popups. In fact, it has no javascript of any kind. There are text ads at the bottom, which may injected the javascript somehow, or there may have been a rotating banner ad that did it that was since removed, or it may have been on the page and was now removed. Or you may have spyware thats injecting the JS (although that would be stupid, since anything that could do that could spawn the windows directly).
As an interesting aside, check out the numbers on the site hosting that Javascript for a great example of why people spam. 1.5% response rate, compared to 13% for Google, but with 1/55th the cost, it (claims) greater cost effectiveness.
Apple is only switching to Intel because they were getting jacked in the ass by IBM
In fairness, signs point to the reason having more to do with Apple throwing it's weight around like it was still 1997. Note that IBM announced improved PPC chips just weeks after Jobs revealed the Intel Macs.
The idea is to have it all the same as before, closed hardware and everything, just now Intel happens to be making the cpu's.
Every sign points to this not being the case. There's essentially zero closed hardware in a Mac as is anyway - you can, if you're determined enough, build a generic PPC machine and install OS X on it.
OSX would never survive as an OS if it went open to the x86 platform at large.
I'm not so sure about this, assuming that they kept making Macs and didn't just drop them.
A large part of Apples profits are from the iPod and iTunes. That won't go away. A signifigant portion of Apples current customers will stick with them, still buying Apple hardware, regardless of what they do. A portion will be upset of the switch to x86 and will ditch Apple for it - they'll be gone regardless of whether or not they support generic x86.
So the only loss is from customers who would have bought Apple hardware, but now will buy generic and run OS X on it. The question is if this amount of people is large enough that the additional revenue from the greater amount of switchers (low cost of entry, just like the Mini - but without the performance penalty) won't offset it.
I don't think Apple will do it, but I don't think it's an obvious cut & dried case of a loss, either. I think they *may* do it in a few years, if they see a market for it. They certainly wouldn't be starting over from 0 - the core of the Mac market won't be going away.
Untrue in the general case, although courts that accept the validity of an EULA won't look kindly on intentional bypassing of an EULA you know exists. Software that you aquire legitimately is perfectly legal to install and use, whether theres an EULA or not, as per copyright law in the US.
This is just one of the reasons EULAs are totally fucking stupid and the legal hoops companies, the legislature, and the courts have jumped through to make them valid are anti-consumer and ridiculous - there is no need whatsoever for the EULA to support the software industry.
However, sadly, in one case the judge actually relied on the argument that since EULAs are so prevalent, and are a norm in the industry, the defendant should have expected and in fact searched out an EULA if one wasn't presented. Personally, I find such a finding to be a terrible miscarriage of justice as well contrary to the law as written. Must have been one of those activise judges I hear so much about.
They might be using a condensor to extract water from the air, then vaporizing that. That would make this statement just the barest, thinnest line from a lie - truly the work of the marketer.
On behalf of PhDs everywhere: fuck you. Use MD if it's really important for you to flaunt yourself. Or you could just take a hint from *every other* profession in the *entire world*, and not think that your choice of profession entitles you to a special honorific.
I think the issue here is to be more questioning of the authenticity of orders - I doubt they'll want cadets questioning the colonel about orders in person, but the point is that you can't trust the authenticity of an email without verification.
You can make a rootkit for any OS, even a minimal microkernel, unless your OS runs out of ROM or there's similiar hardware level measures in place. A rootkit is the end result of an exploit, not an exploit itself - the tricky part is getting sufficent access to install a rootkit.
The dupe Mickey Mouse described was a rollback glitch. However, a) the supposed evidence for it was faked and b) as described, the glitch would be trivial for Blizzard to track. For performance reasons, you may not log every item exchange, and certainly not every gold piece, but they almost certainly do log when a character is rolled back because of a server error - assuming that the described rollback actually occurs - I've been in glitched instances before and not seen rollback.
Judging from the behavior of in-game trades/mail/sales etc, I suspect that they actually do have some form of transaction management for exchanges.
You can, sort of, but it requires altering your document structure with lots of nested tables. Table layouts in CSS require the same sort of munging, which is why this is a weakness (and a failure) of CSS. As long as CSS can't do layout any better than this (and it can't), and more importantly, until IE gets its head out of its ass, I see very few compelling reasons to use CSS for layout and several to not to. I don't find "semantic markup" a compelling reason, because you can present *better* data by creating an XML format and using that than you can HTML.
Bzzt, troll alarm going off because you are moving the goalposts. You said nothing about classifying tables. You were talking about assigning them "programmatic identifiers" - your words, not mine. It seems you're trying to twist the argument into a different one solely to disagree with me and prolong the argument. That's pointless and boring. Stop it.
Perhaps I was unclear about what exactly I was saying. A list of tables on a site (or in a document) is uninteresting and useless. A list of tables grouped by category or type or some other useful bit of metadata is not. There's no place in HTML to stick these bits of metadata, because the the HTML attributes are all either intended to be human-readable, or are overloaded with specific meanings. An XML dialect allows for the explicit specification of this information, and can be used to generate the human-facing HTML attributes. The same argument holds with, say, images - a list of images in a document isn't usefull. A list of images grouped by subject matter, or by chapter, or by the figure they reference, or any number of other bits of data that you can't embedd in the HTML is more usefull. You could, of course, do something like embedd comments or custom attributes or whatever in your HTML but if you do that you may as well use the XML.
Why would I want to throw away the semantics of HTML for an ad-hoc XML format which is meaningless to everybody outside my organisation? Or are you conceding that this is incorrect?
I'm drawing a difference between XML (any dialect, including XHTML) which includes *only* your marked up data, and HTML "for presentation", which includes things like the divs/spans/ids/classes you need to style it properly and the generic site boilerplate you typically find. Note that the benefits of XHTML over HTML 4.1 for the "presentation" are minimal at best. If you're the rare case where you don't have or want any of that, then go ahead and style your XHTML directly with CSS. However, you will find it difficult to create a nice looking and functional site this way. My standard qualification that this only matters if your site is presenting information that is at all usefull as raw data and not simply in its presented form applies.
It doesn't matter. If all you want is a site map, then all you have to do is generate a bunch of links to a bunch of documents with sensible link text.
Perhaps this is where the confusion lies. I don't see a raw sitemap produced this way of being of any value whatsoever. Especially since your ability to extend this sitemap with more usefull information is limited. In my opinion, using a XML dialect as a storage medium, and not worrying about the semantic correctnes of your HTML is a far more powerful and flexible solution - given the current state of both the CSS spec and it's current implementations.
The containing table is not the parent element though. The parent element can be anything, and any size, and it doesn't matter. The "containing table" is merely an anonymous box that is assumed to exist, it's not part of the DOM, not part of the document and you don't have to create it.
An implicit element is still an element. And it's cute how you totally ignored the second part of my statement, of course, which is "position". You can do cell layout with the CSS2 attributes specifically designed for that - I already knew that. It doesn't change the fact that you still can't position or size elements relative to other arbitrary elements! You can only simulate it via nesting divs and/or spans. And nesting your content in divs and spans means you're altering your content to match your presentation - against the whole point of this semantic markup malarky.
In fact, the fact that CSS is tied to tightly to your content is a wart - it's a direct contradiction to the seperation thats trying to be created.
Make one bigger. The other one gets bigger too. Make one smaller. The other one gets smaller too. Nooo... of course they aren't sized relative to each other. It's... what did you call it? A "coincidence"?
Do you know *why* that happens? Because maybe if you did you'd understand that they aren't being sized relative to each other at all. And if you understood why it was happening, you'd see that the replacement for nested HTML table layout would be... nested DIV table layout.
It wasn't clear you wanted to store a programmatic identifier. Now, what on earth could I use in HTML for that? Maybe... oh I don't know... the id attribute? Again, no need for XML there.
If you *had* to pick an HTML attribute suitable for classifying tables, you'd use the class attribute. Too bad that class has specific semantics relateed to CSS.
XHTML is adequate for documents - it's pretty comprehensive and contains a lot of elements good for documents. It's useless for anything you'd want to put into tables, or for correlating, or anything else interesting. And the lack of precision whicch you casually wave off is very important - H1 is a top level heading, but knowing exactly what that means in context matters if you want to do anything with the data you extract. XML obviously has the same consideration, but because you're using an application specific markup you've got the ability to specify tags as specifically as you want. Additionally, the problem of references (an issue with XML and it's variants in general) can be addressed by storing them seperatly and including them as part of your XSLT, something which can't be done if you store everything in XHTML.
Now, if XHTML as an XML dialect is suitable for your documents, thats great. Store them as that. But store them as that *without* any of the markup or attributes you use for browser display, without any of the boilerplate or the headers or the navigation menus or anything - store it as *data*, not as a "web page". *Then* it's usefull, powerful, semantic content. And it'll still look nice and work right in browsers.
This algorithm only works if you know that there are document titles, where the document titles can appear, that there are headings, where the document headings can appear, which ones are more important, and so on. This information is available for HTML documents because HTML is a standard document format with defined semantics. An arbitrary XML document does not have that unless it conforms to a standard document format like XHTML, in which case the supposed benefits of an arbitrary XML document format vanish.
This algorithm won't work in the generic case simply because while HTML defines a page as having a title, there's no way of knowing what a "page" is in context. Assuming you have a book, a single HTML document could be the whole book, it could be a single chapter, or it could be a single conceptual page. Before you can usefully extract meaning from the markup, you must know more about the structure. This means that generic "parse the HTML and return all the H1 tags" scripts are of limited utility, even if all the HTML in the world was semantic markup.
You are wrong, again. Why didn't you try it? Seriously, I explained exactly how to do it and you didn't bother trying it out. The elements will be sized according to the larger of the two elements' contents. Try it.
Maybe its because you don't know what the hell you're talking about. They're sized to 50% of the containing table, just as with a standard HTML table. They are *not* sized relative to each other, which is why you can't position one relative to the other. It's true that without an explicit width on the parent table, the width will be determined from the content of the cells (a vast improvement over CSS positioning without table-layout), but it still relies on the strict parent-child relationship thats fundamental in CSS.
Maybe it's better suited for you but it's not better suited to everybody consuming your pages. Like the table-on-its-side example I gave.
People who want to consume that data will consume the raw XML.
Why not? You can pull out the heading elements on each page to build a sitemap. If, of course, you are using semantic HTML (e.g. ) and not presentational HTML (e.g. ).
No you can't. Not unless you know what element the heading is contained in (title? h1? h1 class="pageheader"?).
If I have an HTML document, I know exactly what the elements mean. If I have a generic XML document, I'm not going to know what the elements mean unless I can find a specification that describes the semantics, and even then it will be a non-standard data format. Just because the syntax is standard, doesn't mean anything else is.
Bull. You'll know what the tags mean if and only if there is an HTML tag that specifies what a section is, and then only if there's no fuzziness about definitions. The only way you can meaningfully extract information from an HTML document is either through explicit knowledge of what the markup is intended to convey, or by inferring that knowledge by inspecting the document. That is exactly the case with XML as well.
You mean like HTML provides with the summary attribute? No need for XML there.
Sure, if you want to ignore standards and replace whats supposed to be a human-readable summary with a programmatic identifier. Get the best of both worlds and generate your human-readable text from a programmatic identifier, without losing either feature.
With HTML, each chapter would likely be on a separate page. Even if it wasn't, you can extract what you suggest by looking at where the figures are placed in relation to heading elements. Again, no need for XML.
So you need to have implicit knowledge of the structure - either you have to know that a page is one chapter, or you have to know how to extract a meaning from the placement of the image and surrounding tags. Thats stupid as hell - explicitly mark up your data and present that instead.
You are wrong. Set two sibling elements to display: table-cell and set their width to 50%. They are both the same width and height in Firefox, Opera and Konqueror. This is quite useful when you are coding for an intranet or any other situation where you don't have to bother with Internet Explorer.
That doesn't address what I said - both those elements will still be sized and positioned relative to the parent, not to the sibling - the fact that they're the same size in that instance is a coincidence, and it doesn't address the positioning.
You're still generating HTML - and that HTML still has to be laid out by some means. XSLT doesn't save you from that.
Thats exactly the point. The generated HTML is designed to be displayed in a browser, and there's no need to worry about whether or not I can parse it to generate table indexes, because I don't care - the core XML is what I'd use for that. It's better suited anyway.
That's great. Instead of a data format that everyone understands the meaning of (HTML), you want a format that everybody can parse, but nobody understands the meaning of but you. XML doesn't have embedded semantics that makes software magically understand it. XML solves the parsing problem, that is all. XML is a meta language - something in "plain" XML means absolutely nothing until it's associated with a specification people know and care about.
I doubt you can give a usefull example of parsing semantically usefull data out of HTML that doesn't rely on either explicit or implicit assumptions about the data format either. A list of all the UL elements on your site is pretty useless. A list of all of the tables of contents is more usefull, but you won't get that from HTML. Now, I know that HTML actually has a pretty good set of semantic tags and that you can get a lot of information out of your pages, assuming everything is marked up with those tages. But, and this is important, anything thats *not* in HTML leaves you stranded. Thats where the X in XML comes from. Your XML files will be smaller and more concise than your HTML (because it'll contain *just* the data, and little need for the ids/classes/markup used for your styling), so it'll be simpler and easier to extract the data you want. And all the rest of the boilerplate on your site won't be present - just the data, ma'am. You still have to know what the data you want looks like and where it is - but thats an aspect of any sort of data mining and using HTML instead won't save you from that. Moreover, using XML allows you to store rich metadata or other information that you can't (or might not want) to embedd in the HTML. Unless every table in your 1000s of pages is the same thing, then storing metadata about what information is in the table might be worth doing. How about indexing all the images on your site? img tags only allow 2 bits of metadata, both of which are supposed to be human-readable and not best suited for programmatic classification. If your XML files include annotations with, say, chapter and figure references, you could easily extract all the figures associated with a specific chapter. Not so easy with your HTML documents.
I'll be clear - I'm talking *both* about limitations of the CSS spec, *and* of it's current implementations. One thing you cannot do, in any version of CSS, is size or position an element relative to any *other* element except it's immediate parent or the canvas. Period. That's a limitation and it's the root cause of a lot of the spurious divs and spans you see floating around. It is *not* an IE only problem - it's a limitation of the cascade model of CSS, and the fact that it's tied to a parent-child relationship defined by the content rather than being manipulatable by the markup. Its made worse by the poor selector and attribute support in IE, but even if IE supported CSS3 100% it wouldn't go away entirely. Even table-layout doesn't fix this - it simply allows you to apply the classic table layout algorithms to arbitrary elements - but those elements still need to be present. If IE7 would implement table-layout, though, that'd probably be enough for me and I'd move away from tables for my gross page layout (I use CSS for the stuff it supports well, like floating images within text, fiddling bits around, and static content areas. I use tables for content boxes).
There are many other limitations which are caused by current implementations - for example, until IE supports table-layout, you can't get the relative flowing sizing and positioning tables offer without using (of course) tables.
Presenting what *claims* to be semantically usefull markup, while in reality it's laden with non-semantic elements (like div and span) is useless. At least when you declare it as HTML, with tables for layout and everything, you're being up front about what you're presenting. Thats aside from the fact that tables as layout *are* a defacto standard for years now, and while it'd be cool to see a browser with the "rich table" functionality that the w3c suggests (like rendering a table in a data grid style control, rather than the site providing DHTML to do it), we need a lot wider uptake of both CSS support and desire on the part of web designers before thats practical. So, in the meantime, I'm going to be part of the problem. If I actually want to present a useful, semantically marked up version of information, I'll do it with XML. And the HTML I present will be created via XSLT. And thats a lot more powerful and usefull of a model than "semantic HTML" is, or ever will be. Something that too few people ever ask themselves is what the usefullness of this "semantic markup" thing is anyway.
As a final point, the (vast) majority of the HTML I create is done indirectly, via a CMS or a web framework, or whatever. It's the same in a large portion of the sites on the web today. In that environment, the managability of the generated HTML is a minor concern, and the maintenance features of the CSS are overshadowed by the features in the CMS/framework - templates and customized server-side tag libraries provide the same "site wide" updating features, rendering that benefit of CSS moot.
I'm a fan of what CSS allows you to do. I'd really, really like IE to cowboy up and get a full CSS2 implementation going. I'd like even more for a full CSS3 implementation. I think seperating content from presentation is a good idea, although it's not a neccesary as people like to claim it is, and I think that (X)HTML is a crappy way to do it. There's not one application of "pure semantic markup" that wouldn't be better addressed by sending XML instead of HTML. I'd like even more if we broke off from CSS totally, and implemented something a little more flexible and powerful (pseudo-classes, for example, are a total hack). And, of course, I'd like it if this new language was implemented identically and at the same time across all browsers. I'd also like a pony.
and she said this would not have happened if he hadn't taken that smoke. He wasn't himself.
Here's your problem right here. Spend 20 minutes in a rape councilling center and you'll hear this thing over and over again. Don't take statements like this at face value. Above all, it's ridiculous to take this sort of statement as a meaningful indicator of the effects of pot. Your friend is using a classic and well-known psychological defense technique to protect herself from trauma over the experience. *She* doesn't know any more than you do if it was because of the pot or anything else. Hell, if she was 6, as you describe, then her knowledge of exactly what he was on is hardly to be taken for granted anyway. So while I'm sorry for your friend, and I do suggest she has therapy if she hasn't already, she should not be considered some sort of expert on the effects of smoking marijuana because as a child she was molested by someone she thought was stoned.
The effects of drugs on inhibitions are well known. It's fine if you personally don't feel the need to use them, but being aware of what they do and why people use them might help you find common ground in these sort of discussions. It's got nothing do to with "our modern society" per se - recreational drug use has been around for as long as there have been people (might want to study your history of Yoga, for example).
And for the record, weed doesn't "rot your brain", and it's *extremely* unlikely that weed (or hashish [note spelling]) is the sole or even an important factor in any sort of "street case" you're talking about.
*especially* pot. In terms of it's influence on your behavior, it's far less signifigant than any "hard" drug, or even alcohol. And I've never even heard of someone blacking out on pot, not even from the rather ridiculously over-dramatized anti-drug videos they used to show us in high school.
Yes, there is. You can do it with CSS tables. Internet Explorer doesn't understand them, but we're talking about the capabilities of CSS, not the capabilities of Internet Explorer, right?
Maybe you are. I'm talking about not only the CSS standard, but also the usefullness of CSS layout vs. tables in the real world, where implementations matter. Talking about what CSS3 could do if there was 100% browser support might be interesting over a beer, but it's not very usefull when it actually comes to developing web pages.
In any case, there's very few instances where a parent-child relationship isn't available to be used in this way. That's just the nature of web pages - things that are visually related tend to be structurally related too.
Thats why there's no need for lots of semantically meaningless divs and spans in CSS markup, right? So if I go to a CSS advocacy site I shouldn't see any of those, or any suggestions to use those to implement the layouts I want? The direct parent-child relationships needed to "hook" in your CSS are fairly rare. Thats why you end up creating them, either with div/span (meaningless markup, existing for no other reason than to manage layout and in my personal view, a bigger sin than using tables), or by going with tables and dispensing with the notion of semantic markup alltogether.
This is how the "CSS is only good for crappy looking websites" thing got started. Especially when you're limited by practical concerns (IE, essentially), doing this means you *cannot* implement non-trivial layouts. And if you start messing with your markup to support your need for more complex CSS, what exactly is your benefit over tables again?
The biggest problem is that you can't reference other elements in CSS - so, for example, when your designer comes to you and tells you that he wants the picture of the widget aligned with the left edge of the nav menu, there is *no way* to implement this cleanly. You have to either start using fixed positioning and size, so you can calculate beforehand were the edge of menu is, or you need to start wrapping your content up in divs to represet "content boxes" or whatever. Whenever your presentation needs differ from the semantic parent-child relationship you've created, you're screwed.
This is why I advocate leaving your semantic markup in XML, which is suited for it, and treating HTML+CSS as a rich-text markup output from an XSLT transform - XSLT giving you the power to add things like semantically meaningless markup (like div layout boxes) without compromising your "pure" semantic markup. And that supposing that semantic markup is actually valuable, which is actually a pretty iffy proposition in many cases.
Table layout algorithms have been essentially identical in all major browsers for at least 4 years. CSS layout, on the other hand, has at least 4 years to go before it's anywhere close.
I've been using CSS for many years. I've been using tables for many years, too, but don't mistake the fact that I'm aware of deficencies both in the CSS stndard and in it's imlpementations for a lack of knowledge. And the fact that you're telling me I need to use blocks of DIVs to layout my stuff is telling me that you're just another blind herd following CSS monkey, rather than anyone who can actually evaluate the usefullness and appropriateness of claims like "semantic markup". There's no excuse for telling someone to replace thier tables with divs "just because".
And just because you managed to find some stylesheet on a CSS site that you use blindly to work around certain CSS bugs (no doubt without realizing that the stylesheet itself relies on other bugs to work correctly, and the widespread reliance on these bugs is a major obstacle to the uptake of correct CSS implemetations in IE), doesn't mean that CSS incompatibilities are easier to work around than the practically non-existant table ones.
I believe the claim still stands, at least to a degree, because you (still) can't create beautiful layouts in CSS, while maintaining anything like cross browser support or (mind blowingly), user defined styles or overriden text size or even page size - features which are fundamental to the concept of the "semantic" markup which is so beloved of CSS advocates.
Of course, having all these features in some avante-garde fancy art designers wet dream is hard using *any* technology - and thats another fundamental that people skip over, too. Posterware is trivial - CSS garden could be implemented with a big image map much more simply, and a Flash site not only simply but also with more functionality.
For exactly this reason, companies very rarely directly compare themselves to a competitor - even though it's within the ream of fair use of a trademark, nobody wants to litigate over a commercial. There's the secondary reason that they don't want to spend thier own money popularizing someone elses name brand, of course.
That's why the "Pepsi Challenge" is between Pepsi and "some other drinks", or detergent is between whatever and "The market leading brand", etc.
These are the mozilla-specific names for features that are in CSS 3. The dash prefix, by the way, is the correct and standards-compliant way to create extensions.
I believe that -moz-border-radius is already mapped to it's CSS3 name, but if not they will be as CSS3 support is implemented.
Okay, vertical positioning, I'll give you. But fluid layouts? That's not hard at all. Websites are fluid by default, they only stop being fluid when you set explicit widths using fixed units. You can do that with CSS or tables.
There is no way in CSS to say something like "size this element relative to the size of that other element" without a parent-child relationship between them. That's the biggest flaw in CSS and it's supposed "semantic markup", because the parent-child stuff is determined by your *content*, the markup, and not just by the CSS.
Your point about the difficulty of moving stuff around in tables is well taken, but on the other hand compare the difficulty of moving from a 3-column fixed format to a 2-column flowed one in CSS vs tables - the hacks to do that kind of flowed layout (at least cross-browser) will require a total reworking of the CSS, as well as content changes. The table version requires changing a couple tag attributes and some reformatting. And even with the huge amount of CSS hackery required to get a basic "newspaper" style column layout (and it takes a very detailed knowledge of CSS to implement this, although [of course] most people will simply lift it from elsewhere), it *still* doesn't demonstrate the same, intuitive behavior that table rendering does when you size it very small or very large. To the best of my knowledge, you cannot make a column based layout in CSS without defining explicit widths at some point without relying on the table-layout attributes, which are not widely implemented.
And it still grates on my nerves how people will proudly display their hacks with comments and exploiting bugs in parsers and 100s of lines of CSS to create "cross browser" CSS, while at the same time decrying table based markup as "hackish". Here's a hint - your bug reliant stylesheets are actually an *obstacle* to the implementation of proper CSS support in IE.
It isn't valid semantic markup if you have to nest everything in 18 layers of divs and spans to convince a browser to apply your CSS rules correctly, either. There's nothing "less" semantic about using tables instead, and there's some serious advantages - like the fact that all major and most minor browsers will render them identically, that they're far more intuitive, and that they allow re-flowing in a way that you can only do with CSS attributes that are explicitly designed to mimic the layout algorithms of "traditional" tables. Which, of course, IE doesn't implement. And much as it'd be nice to simply use the tags anyway, as a practical matter you can't simply ignore IE unless you're creating a special purposed or otherwise private web site.
HTML is not a semantic markup language, hijackers in the W3C not withstanding. It's a rich text markup format. It always has been. XML is (well, can be) semantic markup, and if you really want to store your pages semantically, use XML (with no styling at all), and transform them with XSLT. Dispense with the ridiculous concept of "semantic HTML", which is useless in practice and almost useless in theory, and try using the correct tools for the right job - XML for storing your content, and HTML for presenting it.
It's really not hard to develop and deploy a client app, especially in an AD environment. Really. Sure, theres issues - but these things have been known about for 10 years or more and are solved problems. In an intranet where you control the client machines (exactly the reason people excuse using IE), theres not even any serious concerns about DLL conflicts or versioning.
Theres all kinds of reasons why "web apps" are stupid. They're highly suited for some specific areas (reporting is an obvious one), and they're really beneficial when you need universal access. Most web apps (and almost certainly something replacing a Citrix deployed app) have none of these requirements and instead trade performance, development time, and functionality in favor of a somewhat easier deployment and a very slightly easier way to issue updates. None of the features that make web browsers good web browsers make them suited for applications. (Almost) none of the features that make good application development environments should be present in a web browser.
Slashdot Mirror
My 5 year old can play World of Warcraft. I don't think I've ever hear anyone blathering about "intuitive" or "simple" controls who knew what the fuck they were talking about.
As an interesting aside, check out the numbers on the site hosting that Javascript for a great example of why people spam. 1.5% response rate, compared to 13% for Google, but with 1/55th the cost, it (claims) greater cost effectiveness.
In fairness, signs point to the reason having more to do with Apple throwing it's weight around like it was still 1997. Note that IBM announced improved PPC chips just weeks after Jobs revealed the Intel Macs.
The idea is to have it all the same as before, closed hardware and everything, just now Intel happens to be making the cpu's.
Every sign points to this not being the case. There's essentially zero closed hardware in a Mac as is anyway - you can, if you're determined enough, build a generic PPC machine and install OS X on it.
OSX would never survive as an OS if it went open to the x86 platform at large.
I'm not so sure about this, assuming that they kept making Macs and didn't just drop them.
A large part of Apples profits are from the iPod and iTunes. That won't go away. A signifigant portion of Apples current customers will stick with them, still buying Apple hardware, regardless of what they do. A portion will be upset of the switch to x86 and will ditch Apple for it - they'll be gone regardless of whether or not they support generic x86.
So the only loss is from customers who would have bought Apple hardware, but now will buy generic and run OS X on it. The question is if this amount of people is large enough that the additional revenue from the greater amount of switchers (low cost of entry, just like the Mini - but without the performance penalty) won't offset it.
I don't think Apple will do it, but I don't think it's an obvious cut & dried case of a loss, either. I think they *may* do it in a few years, if they see a market for it. They certainly wouldn't be starting over from 0 - the core of the Mac market won't be going away.
This is just one of the reasons EULAs are totally fucking stupid and the legal hoops companies, the legislature, and the courts have jumped through to make them valid are anti-consumer and ridiculous - there is no need whatsoever for the EULA to support the software industry.
However, sadly, in one case the judge actually relied on the argument that since EULAs are so prevalent, and are a norm in the industry, the defendant should have expected and in fact searched out an EULA if one wasn't presented. Personally, I find such a finding to be a terrible miscarriage of justice as well contrary to the law as written. Must have been one of those activise judges I hear so much about.
They might be using a condensor to extract water from the air, then vaporizing that. That would make this statement just the barest, thinnest line from a lie - truly the work of the marketer.
On behalf of PhDs everywhere: fuck you. Use MD if it's really important for you to flaunt yourself. Or you could just take a hint from *every other* profession in the *entire world*, and not think that your choice of profession entitles you to a special honorific.
I think the issue here is to be more questioning of the authenticity of orders - I doubt they'll want cadets questioning the colonel about orders in person, but the point is that you can't trust the authenticity of an email without verification.
You can make a rootkit for any OS, even a minimal microkernel, unless your OS runs out of ROM or there's similiar hardware level measures in place. A rootkit is the end result of an exploit, not an exploit itself - the tricky part is getting sufficent access to install a rootkit.
Judging from the behavior of in-game trades/mail/sales etc, I suspect that they actually do have some form of transaction management for exchanges.
You can, sort of, but it requires altering your document structure with lots of nested tables. Table layouts in CSS require the same sort of munging, which is why this is a weakness (and a failure) of CSS. As long as CSS can't do layout any better than this (and it can't), and more importantly, until IE gets its head out of its ass, I see very few compelling reasons to use CSS for layout and several to not to. I don't find "semantic markup" a compelling reason, because you can present *better* data by creating an XML format and using that than you can HTML.
Bzzt, troll alarm going off because you are moving the goalposts. You said nothing about classifying tables. You were talking about assigning them "programmatic identifiers" - your words, not mine. It seems you're trying to twist the argument into a different one solely to disagree with me and prolong the argument. That's pointless and boring. Stop it.
Perhaps I was unclear about what exactly I was saying. A list of tables on a site (or in a document) is uninteresting and useless. A list of tables grouped by category or type or some other useful bit of metadata is not. There's no place in HTML to stick these bits of metadata, because the the HTML attributes are all either intended to be human-readable, or are overloaded with specific meanings. An XML dialect allows for the explicit specification of this information, and can be used to generate the human-facing HTML attributes. The same argument holds with, say, images - a list of images in a document isn't usefull. A list of images grouped by subject matter, or by chapter, or by the figure they reference, or any number of other bits of data that you can't embedd in the HTML is more usefull. You could, of course, do something like embedd comments or custom attributes or whatever in your HTML but if you do that you may as well use the XML.
Why would I want to throw away the semantics of HTML for an ad-hoc XML format which is meaningless to everybody outside my organisation? Or are you conceding that this is incorrect?
I'm drawing a difference between XML (any dialect, including XHTML) which includes *only* your marked up data, and HTML "for presentation", which includes things like the divs/spans/ids/classes you need to style it properly and the generic site boilerplate you typically find. Note that the benefits of XHTML over HTML 4.1 for the "presentation" are minimal at best. If you're the rare case where you don't have or want any of that, then go ahead and style your XHTML directly with CSS. However, you will find it difficult to create a nice looking and functional site this way. My standard qualification that this only matters if your site is presenting information that is at all usefull as raw data and not simply in its presented form applies. It doesn't matter. If all you want is a site map, then all you have to do is generate a bunch of links to a bunch of documents with sensible link text.
Perhaps this is where the confusion lies. I don't see a raw sitemap produced this way of being of any value whatsoever. Especially since your ability to extend this sitemap with more usefull information is limited. In my opinion, using a XML dialect as a storage medium, and not worrying about the semantic correctnes of your HTML is a far more powerful and flexible solution - given the current state of both the CSS spec and it's current implementations.
An implicit element is still an element. And it's cute how you totally ignored the second part of my statement, of course, which is "position". You can do cell layout with the CSS2 attributes specifically designed for that - I already knew that. It doesn't change the fact that you still can't position or size elements relative to other arbitrary elements! You can only simulate it via nesting divs and/or spans. And nesting your content in divs and spans means you're altering your content to match your presentation - against the whole point of this semantic markup malarky.
In fact, the fact that CSS is tied to tightly to your content is a wart - it's a direct contradiction to the seperation thats trying to be created.
Make one bigger. The other one gets bigger too. Make one smaller. The other one gets smaller too. Nooo... of course they aren't sized relative to each other. It's... what did you call it? A "coincidence"?
Do you know *why* that happens? Because maybe if you did you'd understand that they aren't being sized relative to each other at all. And if you understood why it was happening, you'd see that the replacement for nested HTML table layout would be... nested DIV table layout.
It wasn't clear you wanted to store a programmatic identifier. Now, what on earth could I use in HTML for that? Maybe... oh I don't know... the id attribute? Again, no need for XML there.
If you *had* to pick an HTML attribute suitable for classifying tables, you'd use the class attribute. Too bad that class has specific semantics relateed to CSS.
XHTML is adequate for documents - it's pretty comprehensive and contains a lot of elements good for documents. It's useless for anything you'd want to put into tables, or for correlating, or anything else interesting. And the lack of precision whicch you casually wave off is very important - H1 is a top level heading, but knowing exactly what that means in context matters if you want to do anything with the data you extract. XML obviously has the same consideration, but because you're using an application specific markup you've got the ability to specify tags as specifically as you want. Additionally, the problem of references (an issue with XML and it's variants in general) can be addressed by storing them seperatly and including them as part of your XSLT, something which can't be done if you store everything in XHTML.
Now, if XHTML as an XML dialect is suitable for your documents, thats great. Store them as that. But store them as that *without* any of the markup or attributes you use for browser display, without any of the boilerplate or the headers or the navigation menus or anything - store it as *data*, not as a "web page". *Then* it's usefull, powerful, semantic content. And it'll still look nice and work right in browsers.
This algorithm only works if you know that there are document titles, where the document titles can appear, that there are headings, where the document headings can appear, which ones are more important, and so on. This information is available for HTML documents because HTML is a standard document format with defined semantics. An arbitrary XML document does not have that unless it conforms to a standard document format like XHTML, in which case the supposed benefits of an arbitrary XML document format vanish.
This algorithm won't work in the generic case simply because while HTML defines a page as having a title, there's no way of knowing what a "page" is in context. Assuming you have a book, a single HTML document could be the whole book, it could be a single chapter, or it could be a single conceptual page. Before you can usefully extract meaning from the markup, you must know more about the structure. This means that generic "parse the HTML and return all the H1 tags" scripts are of limited utility, even if all the HTML in the world was semantic markup.
Maybe its because you don't know what the hell you're talking about. They're sized to 50% of the containing table, just as with a standard HTML table. They are *not* sized relative to each other, which is why you can't position one relative to the other. It's true that without an explicit width on the parent table, the width will be determined from the content of the cells (a vast improvement over CSS positioning without table-layout), but it still relies on the strict parent-child relationship thats fundamental in CSS.
Maybe it's better suited for you but it's not better suited to everybody consuming your pages. Like the table-on-its-side example I gave.
People who want to consume that data will consume the raw XML.
Why not? You can pull out the heading elements on each page to build a sitemap. If, of course, you are using semantic HTML (e.g. ) and not presentational HTML (e.g. ).
No you can't. Not unless you know what element the heading is contained in (title? h1? h1 class="pageheader"?).
If I have an HTML document, I know exactly what the elements mean. If I have a generic XML document, I'm not going to know what the elements mean unless I can find a specification that describes the semantics, and even then it will be a non-standard data format. Just because the syntax is standard, doesn't mean anything else is.
Bull. You'll know what the tags mean if and only if there is an HTML tag that specifies what a section is, and then only if there's no fuzziness about definitions. The only way you can meaningfully extract information from an HTML document is either through explicit knowledge of what the markup is intended to convey, or by inferring that knowledge by inspecting the document. That is exactly the case with XML as well.
You mean like HTML provides with the summary attribute? No need for XML there.
Sure, if you want to ignore standards and replace whats supposed to be a human-readable summary with a programmatic identifier. Get the best of both worlds and generate your human-readable text from a programmatic identifier, without losing either feature.
With HTML, each chapter would likely be on a separate page. Even if it wasn't, you can extract what you suggest by looking at where the figures are placed in relation to heading elements. Again, no need for XML.
So you need to have implicit knowledge of the structure - either you have to know that a page is one chapter, or you have to know how to extract a meaning from the placement of the image and surrounding tags. Thats stupid as hell - explicitly mark up your data and present that instead.
That doesn't address what I said - both those elements will still be sized and positioned relative to the parent, not to the sibling - the fact that they're the same size in that instance is a coincidence, and it doesn't address the positioning.
You're still generating HTML - and that HTML still has to be laid out by some means. XSLT doesn't save you from that.
Thats exactly the point. The generated HTML is designed to be displayed in a browser, and there's no need to worry about whether or not I can parse it to generate table indexes, because I don't care - the core XML is what I'd use for that. It's better suited anyway.
That's great. Instead of a data format that everyone understands the meaning of (HTML), you want a format that everybody can parse, but nobody understands the meaning of but you. XML doesn't have embedded semantics that makes software magically understand it. XML solves the parsing problem, that is all. XML is a meta language - something in "plain" XML means absolutely nothing until it's associated with a specification people know and care about.
I doubt you can give a usefull example of parsing semantically usefull data out of HTML that doesn't rely on either explicit or implicit assumptions about the data format either. A list of all the UL elements on your site is pretty useless. A list of all of the tables of contents is more usefull, but you won't get that from HTML. Now, I know that HTML actually has a pretty good set of semantic tags and that you can get a lot of information out of your pages, assuming everything is marked up with those tages. But, and this is important, anything thats *not* in HTML leaves you stranded. Thats where the X in XML comes from. Your XML files will be smaller and more concise than your HTML (because it'll contain *just* the data, and little need for the ids/classes/markup used for your styling), so it'll be simpler and easier to extract the data you want. And all the rest of the boilerplate on your site won't be present - just the data, ma'am. You still have to know what the data you want looks like and where it is - but thats an aspect of any sort of data mining and using HTML instead won't save you from that. Moreover, using XML allows you to store rich metadata or other information that you can't (or might not want) to embedd in the HTML. Unless every table in your 1000s of pages is the same thing, then storing metadata about what information is in the table might be worth doing. How about indexing all the images on your site? img tags only allow 2 bits of metadata, both of which are supposed to be human-readable and not best suited for programmatic classification. If your XML files include annotations with, say, chapter and figure references, you could easily extract all the figures associated with a specific chapter. Not so easy with your HTML documents.
There are many other limitations which are caused by current implementations - for example, until IE supports table-layout, you can't get the relative flowing sizing and positioning tables offer without using (of course) tables.
Presenting what *claims* to be semantically usefull markup, while in reality it's laden with non-semantic elements (like div and span) is useless. At least when you declare it as HTML, with tables for layout and everything, you're being up front about what you're presenting. Thats aside from the fact that tables as layout *are* a defacto standard for years now, and while it'd be cool to see a browser with the "rich table" functionality that the w3c suggests (like rendering a table in a data grid style control, rather than the site providing DHTML to do it), we need a lot wider uptake of both CSS support and desire on the part of web designers before thats practical. So, in the meantime, I'm going to be part of the problem. If I actually want to present a useful, semantically marked up version of information, I'll do it with XML. And the HTML I present will be created via XSLT. And thats a lot more powerful and usefull of a model than "semantic HTML" is, or ever will be. Something that too few people ever ask themselves is what the usefullness of this "semantic markup" thing is anyway.
As a final point, the (vast) majority of the HTML I create is done indirectly, via a CMS or a web framework, or whatever. It's the same in a large portion of the sites on the web today. In that environment, the managability of the generated HTML is a minor concern, and the maintenance features of the CSS are overshadowed by the features in the CMS/framework - templates and customized server-side tag libraries provide the same "site wide" updating features, rendering that benefit of CSS moot.
I'm a fan of what CSS allows you to do. I'd really, really like IE to cowboy up and get a full CSS2 implementation going. I'd like even more for a full CSS3 implementation. I think seperating content from presentation is a good idea, although it's not a neccesary as people like to claim it is, and I think that (X)HTML is a crappy way to do it. There's not one application of "pure semantic markup" that wouldn't be better addressed by sending XML instead of HTML. I'd like even more if we broke off from CSS totally, and implemented something a little more flexible and powerful (pseudo-classes, for example, are a total hack). And, of course, I'd like it if this new language was implemented identically and at the same time across all browsers. I'd also like a pony.
Here's your problem right here. Spend 20 minutes in a rape councilling center and you'll hear this thing over and over again. Don't take statements like this at face value. Above all, it's ridiculous to take this sort of statement as a meaningful indicator of the effects of pot. Your friend is using a classic and well-known psychological defense technique to protect herself from trauma over the experience. *She* doesn't know any more than you do if it was because of the pot or anything else. Hell, if she was 6, as you describe, then her knowledge of exactly what he was on is hardly to be taken for granted anyway. So while I'm sorry for your friend, and I do suggest she has therapy if she hasn't already, she should not be considered some sort of expert on the effects of smoking marijuana because as a child she was molested by someone she thought was stoned.
The effects of drugs on inhibitions are well known. It's fine if you personally don't feel the need to use them, but being aware of what they do and why people use them might help you find common ground in these sort of discussions. It's got nothing do to with "our modern society" per se - recreational drug use has been around for as long as there have been people (might want to study your history of Yoga, for example).
And for the record, weed doesn't "rot your brain", and it's *extremely* unlikely that weed (or hashish [note spelling]) is the sole or even an important factor in any sort of "street case" you're talking about.
*especially* pot. In terms of it's influence on your behavior, it's far less signifigant than any "hard" drug, or even alcohol. And I've never even heard of someone blacking out on pot, not even from the rather ridiculously over-dramatized anti-drug videos they used to show us in high school.
Maybe you are. I'm talking about not only the CSS standard, but also the usefullness of CSS layout vs. tables in the real world, where implementations matter. Talking about what CSS3 could do if there was 100% browser support might be interesting over a beer, but it's not very usefull when it actually comes to developing web pages. In any case, there's very few instances where a parent-child relationship isn't available to be used in this way. That's just the nature of web pages - things that are visually related tend to be structurally related too.
Thats why there's no need for lots of semantically meaningless divs and spans in CSS markup, right? So if I go to a CSS advocacy site I shouldn't see any of those, or any suggestions to use those to implement the layouts I want? The direct parent-child relationships needed to "hook" in your CSS are fairly rare. Thats why you end up creating them, either with div/span (meaningless markup, existing for no other reason than to manage layout and in my personal view, a bigger sin than using tables), or by going with tables and dispensing with the notion of semantic markup alltogether.
The biggest problem is that you can't reference other elements in CSS - so, for example, when your designer comes to you and tells you that he wants the picture of the widget aligned with the left edge of the nav menu, there is *no way* to implement this cleanly. You have to either start using fixed positioning and size, so you can calculate beforehand were the edge of menu is, or you need to start wrapping your content up in divs to represet "content boxes" or whatever. Whenever your presentation needs differ from the semantic parent-child relationship you've created, you're screwed.
This is why I advocate leaving your semantic markup in XML, which is suited for it, and treating HTML+CSS as a rich-text markup output from an XSLT transform - XSLT giving you the power to add things like semantically meaningless markup (like div layout boxes) without compromising your "pure" semantic markup. And that supposing that semantic markup is actually valuable, which is actually a pretty iffy proposition in many cases.
I've been using CSS for many years. I've been using tables for many years, too, but don't mistake the fact that I'm aware of deficencies both in the CSS stndard and in it's imlpementations for a lack of knowledge. And the fact that you're telling me I need to use blocks of DIVs to layout my stuff is telling me that you're just another blind herd following CSS monkey, rather than anyone who can actually evaluate the usefullness and appropriateness of claims like "semantic markup". There's no excuse for telling someone to replace thier tables with divs "just because".
And just because you managed to find some stylesheet on a CSS site that you use blindly to work around certain CSS bugs (no doubt without realizing that the stylesheet itself relies on other bugs to work correctly, and the widespread reliance on these bugs is a major obstacle to the uptake of correct CSS implemetations in IE), doesn't mean that CSS incompatibilities are easier to work around than the practically non-existant table ones.
Of course, having all these features in some avante-garde fancy art designers wet dream is hard using *any* technology - and thats another fundamental that people skip over, too. Posterware is trivial - CSS garden could be implemented with a big image map much more simply, and a Flash site not only simply but also with more functionality.
That's why the "Pepsi Challenge" is between Pepsi and "some other drinks", or detergent is between whatever and "The market leading brand", etc.
I believe that -moz-border-radius is already mapped to it's CSS3 name, but if not they will be as CSS3 support is implemented.
There is no way in CSS to say something like "size this element relative to the size of that other element" without a parent-child relationship between them. That's the biggest flaw in CSS and it's supposed "semantic markup", because the parent-child stuff is determined by your *content*, the markup, and not just by the CSS.
Your point about the difficulty of moving stuff around in tables is well taken, but on the other hand compare the difficulty of moving from a 3-column fixed format to a 2-column flowed one in CSS vs tables - the hacks to do that kind of flowed layout (at least cross-browser) will require a total reworking of the CSS, as well as content changes. The table version requires changing a couple tag attributes and some reformatting. And even with the huge amount of CSS hackery required to get a basic "newspaper" style column layout (and it takes a very detailed knowledge of CSS to implement this, although [of course] most people will simply lift it from elsewhere), it *still* doesn't demonstrate the same, intuitive behavior that table rendering does when you size it very small or very large. To the best of my knowledge, you cannot make a column based layout in CSS without defining explicit widths at some point without relying on the table-layout attributes, which are not widely implemented.
And it still grates on my nerves how people will proudly display their hacks with comments and exploiting bugs in parsers and 100s of lines of CSS to create "cross browser" CSS, while at the same time decrying table based markup as "hackish". Here's a hint - your bug reliant stylesheets are actually an *obstacle* to the implementation of proper CSS support in IE.
HTML is not a semantic markup language, hijackers in the W3C not withstanding. It's a rich text markup format. It always has been. XML is (well, can be) semantic markup, and if you really want to store your pages semantically, use XML (with no styling at all), and transform them with XSLT. Dispense with the ridiculous concept of "semantic HTML", which is useless in practice and almost useless in theory, and try using the correct tools for the right job - XML for storing your content, and HTML for presenting it.
Theres all kinds of reasons why "web apps" are stupid. They're highly suited for some specific areas (reporting is an obvious one), and they're really beneficial when you need universal access. Most web apps (and almost certainly something replacing a Citrix deployed app) have none of these requirements and instead trade performance, development time, and functionality in favor of a somewhat easier deployment and a very slightly easier way to issue updates. None of the features that make web browsers good web browsers make them suited for applications. (Almost) none of the features that make good application development environments should be present in a web browser.