| 10:13 | <zcorpan> | jgraham: nice :) |
| 13:21 | <Lachy> | I just discovered that TimBL's original list of HTML tags from 1991 had elements for highlighting. I wonder if the intention was similar to the <m> element. http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html#20 |
| 13:54 | <zcorpan> | Lachy: also see html 3.0 |
| 13:55 | <Lachy> | zcorpan, at what specifically? |
| 14:02 | <zcorpan> | hmm, i thought html 3.0 had elements for hightlight too, but can't find it |
| 14:05 | <zcorpan> | i might have mixed it up with html 1 |
| 16:15 | <zcorpan> | hmm, i think annevk will need to update his smil namespace documentation for smil 3.0 |
| 16:56 | <zcorpan> | http://lists.w3.org/Archives/Public/www-smil/2007JulSep/0060.html |
| 19:38 | <KevinMarks> | is it just me, or did firefox mac get all beachball-spinny very often with a recent update? |
| 20:45 | <jruderman> | KevinMarks: which recent update? 2.0.0.6? trunk nightly? |
| 21:00 | <KevinMarks> | 2.0.0.6 |
| 21:39 | <Philip`> | What's up with data:text/html,<p><![CDATA[ ]]]>123456789</p> in Opera 9.2? (It says "9") |
| 21:39 | <Philip`> | (It acts differently in the Live DOM Viewer) |
| 21:40 | <jruderman> | too many "]" characters? |
| 21:41 | <Philip`> | That's just Opera's normal crazy CDATA parsing - I'm wondering why it's discarding all but the last character in the text |
| 21:41 | <jruderman> | discarding entirely or not displaying? |
| 21:42 | <Dashiva> | If you remove all the digits, it displays the > |
| 21:42 | <Dashiva> | And so on until you're only left with <![CDATA[ ] displaying the ] |
| 21:42 | <Philip`> | The characters are not in the DOM at all |
| 21:42 | <Philip`> | http://canvex.lazyilluminati.com/misc/dom-viewer/?%3Cp%3E%3C!%5BCDATA%5B%20%5D%5D%5D%3E123456789%3C%2Fp%3E |
| 21:43 | <Philip`> | If I remove the </p> then it shows all of the characters (including the <![CDATA[... as plain text) |
| 21:44 | <Dashiva> | So the </p> triggers reparsing, then... |
| 21:44 | <Philip`> | It's the < rather than the </p> |
| 22:38 | jgraham | is so confused by Rob Burn's latest message |
| 23:11 | Lachy | wonders what Rob's criteria is for a page to be considered XHTML content?! |
| 23:12 | <Lachy> | he seems to think that anything that isn't well formed isn't XHTML, and so can be ignored in any study. So effectively, 100% of pages that he would classify as XHTML would be well formed |
| 23:19 | <jgraham> | Indeed. I don't think that's a sensible point of view but I'm not sure it's worth discussing |
| 23:20 | <Lachy> | of course it's not worth discussing, it's worth ignoring |
| 23:22 | <webben> | How broken can XHTML be and still actually be XHTML? |
| 23:23 | <jgraham> | webben: In the context of the discussion, it's about authorial intent. |
| 23:24 | <jgraham> | authors who use XHTML doctypes presumably think they are authoring XHTML |
| 23:24 | <webben> | jgraham: I doubt that's true of the majority of documents actually. |
| 23:25 | <jgraham> | Why are they labelling their documents as XHTML then? |
| 23:25 | <othermaciej> | it's hard to tell how to detect XHTML intent |
| 23:25 | <othermaciej> | but if it has an XHTML doctype, an XHTML namespace declaration and some elements with minimized syntax, odds are good there was some intent |
| 23:25 | <othermaciej> | or if it has a "valid xhtml!" button |
| 23:26 | <webben> | jgraham: you're assuming it's a deliberate decision rather than a) what their authoring tool does automatically or b) copy and paste or c) they have no idea that there's a difference between XHTML and HTML |
| 23:26 | <webben> | given the adoption of faux-XHTML by common tools like WordPress, I suspect case a) is probably the most widespread |
| 23:26 | <jgraham> | c is more-or-less a superset of a and b |
| 23:27 | <jgraham> | actually I guess not |
| 23:27 | <webben> | they may or may not go together. |
| 23:28 | <jgraham> | Even if the author has delegated responsibility to their tool author you have to wonder why tools would label documents as XHTML if they did not intend them to conform to XHTML |
| 23:29 | <webben> | jgraham: Sure. But that's a rather different thing to /authorial/ intent. |
| 23:31 | <jgraham> | OK, but the essential point is that at some stage people have made a choice to label the documents as XHTML even though they probably do not conform to the XHTML spec and cannot be processed by XML tools |
| 23:31 | <webben> | (And I think the answer boils down to a sort of marketing gimmick.) |
| 23:31 | <webben> | WordPress devs don't seem to spend a lot of effort on XHTML conformance. |
| 23:32 | <webben> | jgraham: Sure. But those people often aren't the authors of the documents. |
| 23:35 | <jgraham> | webben: Let me restate my position because I don't think I have made it clear. As far as I am concerned documents that are delivered in such a way that they are processed by the XML pipeline in browsers are XHTML. |
| 23:35 | <jgraham> | Other documents are pseudo-XHTML |
| 23:36 | <jgraham> | However these are usually the interesting documents to find out what people who think they are producing XHTML do - |
| 23:36 | <jgraham> | unlike Rob, I think Philip`looked at exactly the right thing |
| 23:38 | <webben> | jgraham: But do WordPress devs really think they are producing XHTML? And are the resultant documents, typically highly corrupted by plugins and commenters etc, really representative of what WordPress devs are aiming to do? |
| 23:39 | <webben> | And, perhaps more importantly, how much difference would it really have made if they'd chosen an HTML doctype? |
| 23:39 | <jgraham> | I don't know what the wordpress devs think they are doing. I do seem to remember that #some people tried to convince them to relabel their documents as HTML and they refused |
| 23:40 | <webben> | (yeah, I was one of them ;) ... one of the key defences is that their showcase blogs only failed to be XHTML because of their plugins ... but there aren't that many WP blogs without plugins) |
| 23:40 | <webben> | I think the conclusion is that WordPress uses the XHTML doctype as a fashion statement. |
| 23:41 | <jgraham> | to me? It makes no difference either way as long as they understand that for every difference that exists between XHTML-as-XML and HTML their "XHTML" will behave like HTML |
| 23:41 | <jgraham> | I think saying "XHTML can be served in such a way that it is processed as HTML" is harmful because it forces everyone to know that |
| 23:42 | <jgraham> | list of differences |
| 23:42 | <webben> | yep, it's highly problematic. |
| 23:47 | <webben> | But if pseudo-XHTML is largely adopted as a fashion statement by tool devs, then if you want to know what problems people are trying to solve with XHTML, XML-served XHTML is likely to be a more interesting sample. |
| 23:48 | <webben> | The one caveat there being that many of the languages one's supposed to only be able to use with XHTML can actually be served with text/html content (e.g. MathML, Ruby). |
| 23:51 | <jgraham> | The thread wasn't about the problems that XML can solve though, it was about whether to endorse XHTML as text/html |
| 23:52 | <othermaciej> | I think the spec should just say you MUST NOT send content that isn't conforming HTML5 (classic serialization), even if it is conforming XHTML5 |
| 23:53 | <othermaciej> | as text/html that is |
| 23:53 | <webben> | Sorry, I haven't actually read the thread. I was just reacting to what was being said on here. |
| 23:53 | <webben> | What would "endorse" mean in this context. |
| 23:53 | <jgraham> | webben: I have great sympathy for not reading the thread :) |
| 23:54 | <jgraham> | "XHTML documents served as text/html result in interoperable behavior |
| 23:54 | <jgraham> | in typical cases, so that constraint [XHTML must be sent using an XML MIME type] is too strong. Please change |
| 23:54 | <jgraham> | it to "SHOULD be sent..." " |
| 23:54 | <jgraham> | is roughly what DanC said |
| 23:55 | <webben> | othermaciej: What would that actually mean, as a conformance criterion though? That tools (e.g. Apache? WordPress) cannot serve HTML 4.01 /or/ HTML5 and be conforming? |
| 23:56 | <webben> | Or is it purely tautologous? That when serving HTML5 as text/html, tools must serve the text/html serialisation of HTML5? |
| 23:57 | <othermaciej> | webben: it would mean that a document is not conforming to the HTML5 specification if it is sent as text/html and is not conforming to the HTML serlialization of HTML5, even if it happens to be conforming to the XML serialization |
| 23:57 | <othermaciej> | webben: this would be a change from the previous registration of the text/html MIME type |
| 23:58 | <webben> | How? The existing registration doesn't mention HTML5 presumably? |
| 23:58 | <webben> | (The actual conformance criterion sounds okay, I just don't see how it's a change rather than an addition.) |
| 23:59 | <othermaciej> | the existing registration says that you may send HTML of any version up to 4.01 or XHTML 1.0 as text/html |
| 23:59 | <webben> | but that's consistent, since HTML5 is later than either. |