Jump to content

Daniel0

Staff Alumni
  • Posts

    11,885
  • Joined

  • Last visited

Everything posted by Daniel0

  1. The thing is that a document is only XHTML if its mime type is application/xhtml+xml, so that is what it takes to make it valid. However, Internet Explorer doesn't support that, so you'll have to do text/html instead, but if you do that it's no longer XHTML, but HTML with XHTML syntax, which is invalid. For instance <br /> is valid XHTML, but invalid HTML. It does work, but it is not correct/valid. It works because HTML is forgiving of errors. You have a couple of options: Use HTML syntax and MIME type text/html. This is valid. Use XHTML syntax and MIME type application/xhtml+xml. This is also valid, but you'll cut off all Internet Explorer users. Use XHTML syntax with MIME type text/html. This is invalid, but it does work (kind of). While a lot of people do it, it doesn't really make sense. First of all, your XHTML code will not be parsed as XHTML thus you will not be able to use any of the extra things XHTML offers (namespaces, etc.). Therefore, I think that using HTML 4.01 Strict is the best option right now. There is nothing wrong with XHTML per se, but it's not a viable option because Internet Explorer has got a large browser market share, but doesn't support XHTML.
  2. No, it doesn't just come down to that. Take this snippet for instance: <table> <tr> <td>1</td> <td>2</td> </tr> <tr> <td>3</td> <td>4</td> </tr> </table> The DOM (Document Object Model) that is generated is not the same for the two content-types text/html (HTML) and application/xhtml+xml (XHTML). Try to check out these two things: http://daniel0.net/html_xhtml_test.php http://daniel0.net/html_xhtml_test.php?xhtml=1 The first one is an HTML 4.01 Strict document served as text/html. The second one is an XHTML 1.0 Strict document served as application/xhtml+xml. Both of them validate on W3C's validator with no errors or warnings. The PHP source code is: <?php $html = !isset($_GET['xhtml']); if (!$html) { header('Content-type: application/xhtml+xml; charset=utf-8'); echo <<<EOF <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> EOF; } else { header('Content-type: text/html; charset=utf-8'); echo <<<EOF <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> EOF; } ?> <head> <?php if ($html): ?> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <?php endif ?> <title>Test (<?php echo $html ? 'HTML' : 'XHTML' ?>)</title> </head> <body> <table> <tr> <td>1</td> <td>2</td> </tr> <tr> <td>3</td> <td>4</td> </tr> </table> </body> </html> As you see, the table is identical in both versions. Or is it? Well, no. In HTML, there is an optional <tbody> element, meaning it will be there whether you've put it in there or not. In XHTML there is no such thing as optional elements; either they are there or they are not. There are loads of other subtle (and less subtle) differences between HTML and XHTML.
  3. I wrote a script that removes duplicate news rows in the database. It removed 322 rows. Note to admins: That script is called remove_duplicate_news.php in /root.
  4. Damn. Stupid syndication script must have broken again. Stupid crap. Oh well, I've disabled the cron job for now. I'll have to look into the bug later.
  5. Sorry, that's not how PHP works. Let's say we use Apache and PHP as a module. So, first you load the module. Then you add a line like this: AddType application/x-httpd-php .php in Apache's configuration file. What this line does is that it for any file with the extension .php, the MIME type should be application/x-httpd-php. However, the when you load the PHP module, Apache is being told all pages with the MIME type application/x-httpd-php should be sent by PHP first. When PHP is parsing a document it looks for things within <?php and ?> tags. Only data that is within these are PHP. Everything else is unknown and returned verbatim. So PHP parses things with the PHP tags (if there are any) and sets the Content-type to text/html (which can be changed by setting the default_mimetype directive or sending a header manually). That is entirely not what is going on when you send a text/html document to a browser. What that says is that the entire document is HTML, so the entire document will be treated as HTML. That is unlike PHP where only the things within its delimiters are treated as HTML. Now, an HTML parser is required to be forgiving, so whenever it meets something that is invalid or unknown it is required to try to correct it, insofar possible. But really, have you read this topic? If you have you'll know that the difference between HTML and XHTML is not just about syntax. The DOM will be different depending on which one you use. I don't think you said this yet, but many people claim that XHTML is better because it's stricter. That may or may not be true, but either way it's paradoxical that these particular people exploit the fact that HTML is forgiving to make their strict "XHTML" work. I'm not sure why you keep riding on that "fake" thing. Obviously you're not supposed to interpret it as fake in the literal sense. That's kind of why you use the little "" signs. The correct word is of course invalid.
  6. Things served as text/html are treated as HTML, things served as image/png are treated as PNG, things served as text/plain is treated as plain text. It's common sense, and it's how the HTTP protocol works; you treat things like the content-type header says it is. It doesn't make sense if it should handle any other arbitrary data. So do you expect that if you put Haskell, Ada or C that it would interpret and execute that as well? Probably not, so why do you expect the same for XHTML? Sure, I can distinguish between these languages, but a computer cannot, so it just assumes you aren't lying. Also, what do you mean with "PHP is ignored". The browser doesn't ignore PHP. You are also contradicting yourself. You say "the xml bits will be ignored". If you ignore the XML bits in XHTML then it is per definition not XHTML. When parsing HTML you specifically ignore invalid things and try to serve it up anyways. Just because it doesn't have draconian error handling like XML and halts at a syntax error doesn't mean that it regards the invalid data as valid, or accepts anything you give it. Again, I would recommend you to read the topic. You are hardly bringing anything new to the discussion.
  7. http://www.w3.org/TR/xhtml-media-types/#text-html You can do a quick little check yourself. Find an "XHTML" document served as text/html (e.g. this page) and then find a self-closed tag. Check the source in Firefox. Notice that the / is in red. Now create an XHTML page and serve it as application/xhtml+xml. Notice that it is no longer red. Why does this happen? Well, something like <br /> is invalid HTML, so if you tell the browser via the content-type header that it's HTML, it'll treat it as HTML. Firefox marks up syntax errors in red. Try to make a a more drastic syntax error and notice the red-ness. I would recommend you to read the thread I linked to. It has already been discussed, and I believe I proved some additional examples of how the parsing differs if you use text/html versus application/xhtml+xml. If you have anything new to add, I'd be happy to discuss it with you in that topic. I'm not interested in reiterating myself, however.
  8. That is not what I said at all. XHTML served as text/html is "fake" HTML, or rather invalid HTML. There is a long topic about it here: http://www.phpfreaks.com/forums/index.php/topic,241805.0.html
  9. Any version. IE doesn't support XHTML at all. It supports fake "XHTML" that is served (and thus parsed and handled) as HTML, sure, but it has never supported XHTML.
  10. Why would disabling UAC remove your cookies? Your own cookies are readable by yourself anyway, thus removing it with UAC on wouldn't result in a UAC prompt. In short, UAC has nothing to do with your own cookies.
  11. Sorry, but what is a UED?
  12. Try setting quality=100 when calling imagejpeg. By the way, it's called JPEG artifacts, not pixelation. That's something different. Pixelation is when the individual pixels in a picture is visible to the human eye. That's not the case here. JPEG artifacts occur because JPEG is using lossy compression, like AlexWD said.
  13. It supports cascading deletes (and updates) using constraints in InnoDB.
  14. Look up constraints in InnoDB.
  15. Try this: $text = preg_replace('#^%([^%]+)$#', '%$1%', $text); Edit: Updated regex.
  16. Obviously it means shutting down civilian connections within the US. Much like Iran did a while ago. Due to its decentralized nature, the internet cannot just be shut down by a single person. Even if you could it would be a retarded thing to do.
  17. The search index is being rotated, but that operation takes less than a second.
  18. Daniel0

    wtf???

    It's entirely possible that speakers can intercept radio traffic. I was in a math course this summer with a person who had that problem as well.
  19. Well, you can just do like this: function addBook($obj){ $this->shelf->attach($obj); } Because your method isn't returning anything.
  20. We aren't running hourly backups on this server. That's being done on another server. This one only does daily backups at midnight server time.
  21. You could use AJAX and progressive enhancement. In that way it could always fall back on creating a new full request if Javascript was unavailable.
  22. [daniel@phpfreaks ~]$ uptime 11:09:38 up 50 days, 17:49, 1 user, load average: 0.12, 0.13, 0.09 Not our server at least.
  23. Personally, I prefer OOP over procedural any time. I simply think it's much better suited for especially larger applications. It's much easier to structure your code, encapsulate things and extend things. In PHP I virtually never write procedurally unless it's a small test snippet I'm writing.
  24. Depends on the context.
  25. Sorry, but that argument sucks. Why buy meat from the supermarket when you can breed cows and slaughter them yourself? Why buy cars when you can take an engineering degree and make them yourself? Why take engineering degrees when you can read books yourself and read? Why buy books when you can experiment and come to the same results yourself? The problem with that mindset is that you enter an infinite loop. When are you going to stop? When will it be okay to rely on other people's services? Moreover, instead of being really good at one thing or a couple of things, you'll end up being average or mediocre at a lot of things. Hypothetically, let's say you have cancer. Which person would you like to treat you? The doctor who knows something about virtually all branches of medicine, but has no particular specialty, or the doctor who has chosen to specialize in cancer, but whose knowledge is lacking in other areas of medicine? The point of that example is of course that the people who have specialized in creating HD artwork/movies will almost surely create something significantly better than you will. Pick an area you like and want to be good at instead of picking 15 areas to be mediocre at. You constantly come up with some new thing you want to master, but I'm sorry to say it, but you will never master something unless you focus on that particular thing. You have a finite amount of time available, so the more things you wish to learn the less time there will be for each of these things. It also seems you're oblivious to the way virtually the entire world works. Person A has skills x and y, so these are the services he can offer for other people. However, he doesn't know how to do z and q (and a lot of other things), so he has to get other people to do that for him. Person B is good at q, so he can do it for person A (for some sort of compensation (either money or a favor)). If you're trying to subvert that system you're up for a really tough task.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.