| 00:01 | <Hixie> | if <div>-containing-inline is "thematic group", what's the difference between <div> and <p>? |
| 00:01 | <Hixie> | maybe i should just bite the bullet and make them equivalent in the spec |
| 00:01 | <Hixie> | <div>-containing-inline and <p>, i mean |
| 00:01 | <Hixie> | not <div>-containing-block |
| 00:02 | <zcorpan> | i would be ok with that |
| 00:19 | <zcorpan> | Hixie: somehow your scripts converted "<code title="attr-style-scoped">scoped</code> attribute" to "<code title=attr-style-scoped><a href="#scoped"></a></code>" |
| 00:20 | <Hixie> | i probably edited the file while the thing was being generated |
| 00:20 | <Hixie> | i'm using bert's script to do the cross-references |
| 00:20 | <Hixie> | it runs on cgi.w3.org |
| 00:20 | <Hixie> | and takes three years per generetion |
| 00:20 | <zcorpan> | ok :) |
| 00:21 | <Hixie> | and i have to do two each time i do a checkin (one for the w3.org version and one for the whatwg.org version) |
| 00:22 | <zcorpan> | oh yep |
| 00:23 | <Hixie> | so that's six years :-P |
| 00:24 | <Hixie> | yeah, looks like i changed the file while i was generating it |
| 00:24 | <Hixie> | d'oh |
| 00:24 | <Hixie> | oh well |
| 00:24 | <Hixie> | fixed |
| 00:33 | <Hixie> | i wonder why i used a different technique for <xmp> as for the other CDATA elements |
| 00:53 | <webben> | Hixie: If div may be used for custom widgets (as it is in the wild), then treating div with inline children like p would presumably break paragraph to paragraph navigation. |
| 00:54 | <webben> | Is your current view that div-as-custom-widget be conforming, non-conforming but specified, or non-conforming and unspecified? |
| 00:55 | <webben> | Hixie: Having said that, it might be worth defining special parsing for p containing certain children, such as blockquote. |
| 00:55 | <webben> | (where stuff which can go into print paragraphs cannot go into text/html paragraphs) |
| 00:56 | <webben> | *special parsing for div containing certain children, sorry |
| 00:56 | <Hixie> | webben: conforming but discouraged in favour of things like xbl2 |
| 00:58 | <webben> | Hixie: How about processing WAI-ARIA attributes for such widgets then? |
| 00:58 | <webben> | which category would that fall into? |
| 01:03 | <webben> | btw examples of paragraph-by-paragraph navigation include: https://addons.mozilla.org/en-US/firefox/addon/2266 and http://images.apple.com/accessibility/voiceover/pdf/VoiceOverKeyboard_Color_v2.pdf and http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_rnib003398.hcsp and http://www.gwmicro.com/window-eyes/manual/html/index.html?appendix_a_1.htm (though note this doesn't necessarily equal navigation by <p>) |
| 01:03 | <webben> | e.g. "Window-Eyes defines paragraphs as any collection of elements that contain blank space both above and below the collection, regardless of whether that collection contains text, or any other element." |
| 01:04 | <Hixie> | i don't really understand any of your questions :-) |
| 01:04 | <Hixie> | we already have, e.g., <li> defined to be a paragraph |
| 01:04 | <Hixie> | i don't understand what the processing of WAI-ARIA would get us (they're woefully underdefined and redundant with most of what's already in HTML anyway) |
| 01:06 | <webben> | Hixie: It seems to be a fundamental premise of WAI-ARIA to prefer native widgets where available (which seems to be exactly the same as the position you're suggesting WHATWG adopt). WAI-ARIA is clearly not redundant for custom widgets since they aren't in HTML. |
| 01:06 | <webben> | Hixie: They don't seem to be so underdefined that Mozilla and AT can't implement them. |
| 01:07 | <webben> | Does WHATWG have an alternative proposal for accessifying such widgets in current browsers and AT? |
| 01:08 | <Hixie> | WAI-ARIA is redundant for most (all?) the widgets it supports, as they are all defined in HTML5 as far as I can tell. |
| 01:09 | <webben> | Hixie: WAI-ARIA doesn't support just a set of widgets but also a set of properties and states. Can Dojo use HTML5 widgets in current UAs and have them look as "nice" as their existing widget set? |
| 01:10 | <webben> | Mozilla doesn't seem to support some of the more basic HTML5 widgets yet ... e.g. slider. |
| 01:11 | <othermaciej_> | HTML5 doesn't define how to do widgets with custom look or behavior (in itself) |
| 01:11 | <Hixie> | they are underdefined, for example it is not at all clear what it would mean if you had a document with a wairole:treeitem as a child of a waitrole:checkbox or some such |
| 01:11 | <Hixie> | WAI-ARIA and HTML5 both define new technologies, and therefore don't work in legacy UA ATs |
| 01:11 | <webben> | Hixie: Legacy UA AT != current UA ATs |
| 01:11 | <Hixie> | by "Legacy UA AT" i mean the currento nes |
| 01:12 | <Hixie> | ones |
| 01:12 | <Hixie> | as opposed to the ones that support the technologies in question |
| 01:14 | <webben> | Hixie: The breakage is not the same. You cannot write Dojo widgets in HTML5 and get them to look "nice" in IE. But you can write Dojo widgets and get them to look "nice" in all modern browsers, but also be accessible in Mozilla (and thus to major AT). |
| 01:15 | <Hixie> | i disagree, but that's not really important |
| 01:15 | <webben> | With which bit? The cannot or the can? |
| 01:15 | <Hixie> | that you can't use the HTML5 elements and have them look good in IE |
| 01:16 | <Hixie> | it's just a matter of using the right elements and then replacing them in script with whatever you want to replace them with |
| 01:16 | <Hixie> | but anyway, i'm more interested in the long term solution to this |
| 01:16 | <Hixie> | which is, imho, to use xbl2 and html5 |
| 01:16 | <othermaciej> | (or just CSS styling of form controls for simple cases if there's ever sufficiently interoperable support for that) |
| 01:16 | <Hixie> | yeah |
| 01:17 | <Hixie> | imho the wai-aria/role stuff is a distraction that is merely slowing the adoption rate for the long-term solutions |
| 01:17 | <Hixie> | wai-aria/role aren't scalable, and are far too complicated to implement by most authors |
| 01:17 | <othermaciej> | well, the long-term solutions are much more complex in terms of required browser engineering to deploy |
| 01:18 | <Hixie> | right |
| 01:18 | <webben> | Hixie: I doubt accessibility is the major driver for XBL2 adoption, so I doubt that's the case. |
| 01:18 | <Hixie> | the complexity is placed in the UAs, rather than the authors |
| 01:18 | <webben> | Hixie: Custom widgets are too complicated to implement by most authors full stop. |
| 01:18 | <webben> | (XBL2 is way too complex) |
| 01:18 | <Hixie> | (that's the right way to do it, it reduces the total implementation cost to the human race) |
| 01:18 | <Hixie> | anyway, gotta go, meeting |
| 01:18 | <Hixie> | bbl |
| 02:01 | Philip` | finally gets his multiplayer FPS working cross-browser (or at least across two browsers) |
| 02:58 | Philip` | gets up support for three browsers, which is plenty to say that any problems in other browsers are their fault and not mine |
| 08:06 | <hsivonen> | annevk: svn co http://svn.versiondude.net/whattf/htmlparser/trunk/ htmlparser |
| 08:07 | <hsivonen> | finally got a sane ACL there |
| 08:40 | <zcorpan> | Hixie: "Comment parsing is different." -- not anymore, right? only three parsing quirks left :) |
| 09:17 | <Hixie> | don't kill me |
| 09:18 | <Hixie> | but i'm about to check in major changes to the way <head> is parsed |
| 09:18 | <Hixie> | zcorpan: that i know of :-) |
| 09:18 | <Hixie> | jesus, this is a 1000 line patch |
| 09:21 | <annevk> | dude |
| 09:21 | <annevk> | well, I suppose it gives me some more hacking fun :) |
| 09:22 | <annevk> | or is this the patch that makes EOF work and gives the tree construction stage just a set of phases |
| 09:24 | <annevk> | seems it does indeed take three years before such things make it in :) |
| 09:30 | <Hixie> | no, it's the change that allows <noscript> in <head> |
| 09:30 | <annevk> | oh |
| 09:30 | <Hixie> | btw you might want to give more context for the patches on the tracker page, some of these changes are hard to follow if you don't have 20+ lines of context |
| 09:31 | <annevk> | svn diff ...? |
| 09:31 | <Hixie> | ironically i think the change to fold phases and insertion modes into one might be simpler -- except it'd probably introduce more bugs :-) |
| 09:31 | <Hixie> | dunno what the svn diff command is |
| 09:31 | <annevk> | that should be trivial to fix, if someone gives me the relevant command line options |
| 09:31 | <Hixie> | i use regular gnu diff |
| 09:31 | <Hixie> | in ~/.subversion/config |
| 09:32 | <Hixie> | i have, under [helpers]: |
| 09:32 | <Hixie> | diff-cmd = /home/ianh/.subversion/diff |
| 09:32 | <Hixie> | and that file contains: |
| 09:32 | <annevk> | hmm, I'll figure something out |
| 09:32 | <Hixie> | #!/bin/bash |
| 09:32 | <Hixie> | diff=/usr/bin/diff |
| 09:32 | <Hixie> | args="-u20 --new-file --minimal --show-c-function" |
| 09:32 | <Hixie> | exec ${diff} ${args} "$@" |
| 09:32 | <Hixie> | (--show-c-function isn't useful for the spec) |
| 09:36 | <Hixie> | this checkin makes <head> element parsing much simpler |
| 09:36 | <Hixie> | though it does add a state |
| 09:38 | <Hixie> | right, checked in |
| 09:42 | <hsivonen> | Hixie: FYI, http://golem.ph.utexas.edu/%7Edistler/blog/archives/001324.html in case it didn't appear on your radar already |
| 09:46 | <annevk> | hmm, in theory scripting does not have to be enabled for fragment parsing |
| 09:46 | <Hixie> | hsivonen: i love how some of hte most important issues are relagated to a footnote |
| 09:47 | <Hixie> | annevk: indeed, not any more, not now that it's been abstracted out |
| 09:47 | <Hixie> | the only case i think we don't currently handle is error-handling of <noscript> contents in <head> when parsing is disabled and you're doing fragment parsing for a <head> |
| 09:47 | <Hixie> | not sure i want to both fixing it though |
| 09:49 | <annevk> | yeah, I was reading the diff and spotted that edge case you mentioned there :) |
| 09:52 | <Hixie> | right well, with that checkin, let's try sleeping again |
| 09:52 | <Hixie> | nn |
| 09:52 | <annevk> | g'night |
| 09:54 | <hsivonen> | nn |
| 10:30 | <annevk> | http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0023.html ... |
| 10:34 | <zcorpan> | oh, so it is modularization that makes xhtml. well then, xhtml 1.0 needs a new name, too |
| 10:34 | <annevk> | these discussions don't make sense to me at all |
| 10:35 | <annevk> | but I'm not going to get involved |
| 10:43 | <zcorpan> | so xhtml2 is not terribly different from xhtml1.1, and thus doesn't need a new namespace. html5 however slightly changes the semantics of <i>, and thus needs a new namespace. yep. makes sense. |
| 10:44 | <annevk> | it's not like they don't change the semantics of <input> |
| 10:44 | zcorpan | goes back to writing test cases |
| 10:49 | <othermaciej> | zcorpan: xhtml2 is more backwards-compatible than html5! |
| 10:49 | <othermaciej> | zcorpan: haven't you heard? |
| 10:49 | <zcorpan> | othermaciej: yeah |
| 10:49 | <othermaciej> | also, all XHTMLs have always been modular |
| 10:50 | <othermaciej> | (except the one people actually use on the web) |
| 10:52 | <zcorpan> | i would love to see his comparison though |
| 10:58 | <othermaciej> | well, HTML5 slightly changes the semantics of the <i> element and XHTML2 removes it |
| 10:58 | <othermaciej> | so there's one example where XHTML2 is more compatible |
| 10:59 | <othermaciej> | HTML5 adds some new event listener attributes but XHTML2 removes them all and replaces them with XML Events, so there's another example |
| 11:01 | <zcorpan> | then obviously there are different interpretations on what backwards-compatibility means. is it compatibility with existing UAs or compatibility with prior specs? |
| 11:01 | <othermaciej> | well, XHTML2 doesn't have either |
| 11:01 | <zcorpan> | true |
| 11:03 | <othermaciej> | but it does have modules |
| 11:03 | <othermaciej> | maybe it is compatible in the sense that you could mix and match modules from XHTML 1.1 and XHTML 2 when making your web-fragmenting frankenlanguage profile |
| 11:04 | <zcorpan> | perhaps you would use server-side check if the UA supports xhtml2, and if not, you serve xhtml1.1 |
| 11:05 | <zcorpan> | or use xslt |
| 11:11 | <annevk> | hmm, if citations of minutes are out of context than the minutes have not been done properly... |
| 11:11 | <zcorpan> | Hixie: <noscript><meta http-equiv=refresh> ? |
| 11:12 | <met_> | Steven: I believe that XHTML2 is more backwards compatible than HTML5, and I plan to make a document comparing them to demonstrate it. (cannot iin the irc log see the note about document preparing) |
| 11:13 | met_ | just comparing http://www.w3.org/2007/06/20-xhtml-minutes#item05 and http://krijnhoetmer.nl/irc-logs/xhtml/20070620 |
| 11:15 | <annevk> | interesting |
| 11:16 | <annevk> | they must have edited things |
| 11:16 | <annevk> | not in http://www.w3.org/2007/06/20-xhtml-irc either |
| 11:35 | <annevk> | Ok, http://html5.org/tools/web-apps-tracker now has -up20 enabled and an updated title |
| 11:35 | <annevk> | I'll commit the changes |
| 11:40 | <annevk> | let me know if it is too much context |
| 11:40 | <annevk> | it takes some time for me to get used to it |
| 11:40 | <annevk> | at least |
| 12:23 | <zcorpan> | htmlcollections are fun |
| 12:24 | <annevk> | and browsers are broken? |
| 12:24 | <zcorpan> | no, they work fine, although they don't interoperate on some points |
| 12:25 | <zcorpan> | for document.links, firefox only filters for <area href> when there is a <map> ancestor |
| 12:26 | <zcorpan> | for document.anchors, ie filters for <a> elements with a non-empty id or name attribute |
| 12:26 | <annevk> | that makes sense |
| 12:28 | <zcorpan> | what ie does for .anchors? |
| 12:28 | <Philip`> | When the spec says HTMLCollection has "a [[Get]] method that, ... when invoked with a property name that is a string, acts like the namedItem() method would when invoked with that argument", isn't that wrong because collection['item'] gives the item function and is not the same as collection.namedItem('item')? |
| 12:29 | <zcorpan> | haven't tested namedItem yet |
| 12:29 | <zcorpan> | only which elements that are filtered for so far |
| 12:29 | <zcorpan> | not done with all collections either |
| 12:30 | <zcorpan> | should get some lunch first |
| 12:31 | <annevk> | Philip`, same goes for collection["length"]; I guess that will be solved once [[Get]] is defined at the IDL-level instead of paragraph-level |
| 12:31 | <Philip`> | Oh, actually, <b id=item></b> ... c = getElementsByTagName('b'); c['item'] gives the HTML element in IE6 and Opera, but gives the item function in Firefox |
| 12:31 | <annevk> | ooh |
| 12:32 | <annevk> | cool |
| 12:32 | <Philip`> | (If nothing has id=item, then IE6 and Opera give the item function) |
| 12:32 | <annevk> | not cool |
| 12:47 | <Philip`> | Hmm, there's loads of ways it doesn't match IE6 - there's interesting behaviour in <a id=x></a><a id=null></a><a id=10></a> ... c[null]; c.item(null); c.namedItem(null); c[10]; c["10"]; c.item(10); c.item("10"); |
| 14:12 | <annevk> | interesting |
| 14:12 | <annevk> | for namedItem() it stringifies and for item() it makes itself 0 |
| 14:12 | <annevk> | for c[] it throws |
| 14:14 | <annevk> | hmm... item("10") is weird |
| 14:14 | <annevk> | so is item("null") |
| 14:23 | <Philip`> | Ooh, I never knew you could do something like Object.prototype.toString.call(ctx) to work out the [[Class]] of an object |
| 14:29 | <Lachy> | annevk, don't you agree with my answer to the .match(":root") matching in document fragments? |
| 14:33 | <annevk> | dunno |
| 14:33 | <annevk> | didn't follow all of the discussion |
| 14:34 | <Lachy> | oh, well, read my last post on member-webapi |
| 14:34 | <annevk> | wtf |
| 14:34 | <annevk> | _member_?! |
| 14:34 | <annevk> | bah |
| 14:34 | <Lachy> | yeah, sorry |
| 14:34 | <Lachy> | I didn't start the discussion there, just responded to it |
| 14:35 | <annevk> | hmm, ok |
| 14:35 | <annevk> | it still clashes with the definition of root in HTML5 for lonely elements |
| 14:36 | <annevk> | but maybe that doesn't matter |
| 14:36 | zcorpan | wonders what Lachy's answer was |
| 14:37 | <annevk> | zcorpan, you should be able to look it up now that you're working for Opera |
| 14:37 | <annevk> | zcorpan, if you're in an Opera office that is |
| 14:37 | <Lachy> | zcorpan: basically that in fragments that aren't part of a document, there is no root element |
| 14:38 | <Lachy> | so :root matches nothing |
| 14:38 | <zcorpan> | annevk: how? |
| 14:38 | <zcorpan> | Lachy: ok. makes sense |
| 14:38 | <annevk> | zcorpan, IP white-listing |
| 14:38 | <Philip`> | (Oh, that Object.prototype.toString thing doesn't work in IE (since that just says "[object Object]" all the time), so I guess it's not so helpful for people who care about testing IE :-( ) |
| 14:39 | <zcorpan> | annevk: i don't follow |
| 14:40 | <Lachy> | this one explains it best, if you're able to access it http://lists.w3.org/Archives/Member/member-webapi/2007Jun/0019.html |
| 14:40 | <zcorpan> | i'm not |
| 14:40 | <annevk> | oh, maybe the swedes are not whitelisted |
| 14:40 | annevk | ponders |
| 14:43 | <Lachy> | perhaps I should ask the CSSWG for clarification |
| 15:23 | Lachy | mails www-style about the issue |
| 15:24 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2007Jun/0116.html |
| 15:27 | <annevk> | I'm not sure I argued. I just pointed out that that's what HTML5 says |
| 15:27 | <annevk> | or HTML5 defines as the "root element" |
| 15:29 | <Lachy> | yeah, but Jonas still didn't agree, so I decided it would be worth asking anyway |
| 15:30 | <Lachy> | where does HTML5 actually define the root element? |
| 15:32 | <Lachy> | it does here http://www.whatwg.org/specs/web-apps/current-work/#the-root but that doesn't really apply to fragments in general |
| 15:33 | <Lachy> | there it is http://www.whatwg.org/specs/web-apps/current-work/#root-element |
| 15:34 | <annevk> | that definition doesn't really cover subtrees outside the document though or document fragments |
| 15:35 | <Lachy> | it sort of does. it calls them orphaned nodes |
| 15:53 | <zcorpan> | fun! <table><form><tr><td><textarea>, then check form.elements |
| 15:55 | <Lachy> | it contains the textarea. Isn't that the expected behaviour? |
| 15:55 | <zcorpan> | not in the dom it doesn't |
| 15:55 | <annevk> | it does per HTML5 |
| 15:56 | <annevk> | note how the form element pointer is set |
| 15:56 | <Lachy> | yeah, but I had a feeling HTML5 adds it to the forms collections anyway |
| 15:56 | <annevk> | and if that's not the case, it's a bug :) |
| 15:56 | annevk | checks |
| 15:56 | <zcorpan> | annevk: it will probably be the case when wf2 is merged |
| 15:57 | <annevk> | I meant in the parser |
| 15:57 | <zcorpan> | oh sure |
| 15:57 | <annevk> | I suppose form.elements will be defined in terms of the form element pointer |
| 15:57 | <zcorpan> | yeah. it's not right now though |
| 15:58 | <zcorpan> | wf2 says to look at the ancestors and the form="" attribute |
| 15:59 | <annevk> | fair enough |
| 15:59 | <annevk> | <form> parsing prolly needs more testing than this |
| 16:00 | <annevk> | than it had so far |
| 16:01 | <annevk> | http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0026.html |
| 16:02 | <annevk> | http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0025.html is nice too |
| 16:02 | <annevk> | "nice" |
| 16:04 | <Philip`> | Call it X-HTML5, because it's the XML version of HTML5, so people shouldn't object to that, and then just accidentally drop the hyphen every time you use the name |
| 16:05 | <annevk> | 1) I haven't seen it cause much confusion. 2) Not all XHTML languages are modular. 3) You want a short name for "XML serialization of HTML5" |
| 16:06 | <annevk> | 1) see http://blogsearch.google.com/blogsearch?q=xhtml5 2) see XHTML 1.0 and 3) well... |
| 16:06 | annevk | -> food |
| 16:08 | <duryodhan> | Philip`: your page canvex.illuminati... the one you had said yesterday ... |
| 16:08 | <duryodhan> | I was able to use it from my work comp |
| 16:09 | <duryodhan> | (i.e school comp ) |
| 16:09 | <Philip`> | The http://canvex.lazyilluminati.com/misc/drawwindow.html one? |
| 16:09 | <duryodhan> | I dont know how there it didn't give exception ... |
| 16:09 | <duryodhan> | yeah that one |
| 16:09 | <duryodhan> | from my home it is giving exception |
| 16:09 | <Philip`> | Hmm, sounds odd |
| 16:09 | <duryodhan> | I couldn't contact from school cos it behind a proxy ... IRC blocked :( |
| 16:10 | <Philip`> | Given the danger of letting random web sites show the user a dialog box which they won't read and where they'll click on either button at random to make the dialog box go away, when clicking the wrong button will give the web site complete control over the user's computer, I would expect it to be blocked by default... |
| 16:10 | <duryodhan> | yes ... that is true ... |
| 16:10 | <duryodhan> | but the thing is ... |
| 16:11 | <duryodhan> | it worked |
| 16:11 | <duryodhan> | :D |
| 16:11 | duryodhan | is also suprised how good chatzilla is |
| 16:11 | <Philip`> | But if it works when it shouldn't, that's probably a bug :-) |
| 16:11 | <Philip`> | (or a weird configuration option) |
| 16:11 | <duryodhan> | exactly ... |
| 16:12 | <duryodhan> | what is that weird config ? |
| 16:12 | <duryodhan> | I can probably get away with asking ppl to do it |
| 16:12 | <duryodhan> | rofl |
| 16:13 | <duryodhan> | brb |
| 16:13 | <Philip`> | about:config -> signed.applets.codebase_principal_support = true enables it |
| 16:14 | <duryodhan> | Philip`: aaah |
| 16:15 | <duryodhan> | signed.applets.codebase_principal_support |
| 16:15 | <Lachy> | LOL :-D "Steven: I believe that XHTML2 is more backwards compatible than HTML5, and I plan to make a document comparing them to demonstrate it." -- http://www.w3.org/2007/06/20-xhtml-minutes#item05 |
| 16:15 | <duryodhan> | toggle that and you are golden |
| 16:15 | <duryodhan> | Lachy: well |
| 16:15 | <Philip`> | duryodhan: Toggle that and you're also much less secure :-) |
| 16:15 | <duryodhan> | I believe i can fly .... |
| 16:16 | <duryodhan> | Philip`: not me ... client :D |
| 16:16 | <duryodhan> | Philip`: not less secure ... you should just stop clicking OK blindly |
| 16:16 | <Lachy> | duryodhan: will you produce a document comparing your ability to fly with mine to demonstrate that? |
| 16:16 | <duryodhan> | Lachy: I will even make a canvas base64 image of it for you |
| 16:16 | <duryodhan> | rofl |
| 16:17 | <Lachy> | oh, I'm intrigued now. |
| 16:19 | <Philip`> | duryodhan: As far as I can see, codebase_principal_support doesn't directly make anything less secure - it just allows sites to ask for privileges without being identifiable (i.e. not using certificates and stuff) |
| 16:19 | <Lachy> | I'm confused by the XHTML2 WG's strange belief that altering the semantics slightly makes a language not backwards compatible, whereas completely changing processing requirements like XHTML2 does remains compatible |
| 16:19 | <duryodhan> | Philip`: that is what I was reading up on ... |
| 16:19 | <duryodhan> | Philip`: so If I maybe sign my scripts .... |
| 16:20 | <duryodhan> | Philip`: then maybe it will ask even if that config isn't toggled... |
| 16:20 | <duryodhan> | btw, if you are wondering where in the world I found this obscure option ... see the XML Digital Signature tool Firefox add on |
| 16:20 | <Philip`> | Lachy: It might help if they were clearer on what "backward compatibility" they had in mind (like old/new conforming/nonconforming documents in new/old UAs, with UAs implementing latest/all specification, etc) |
| 16:21 | <Philip`> | (because it seems you get different constraints and conclusions depending on which forms of compatibility you're interested in) |
| 16:21 | <Lachy> | I'll ask steven. I'm waiting for him to get back so I can speak to him in #xhtml |
| 16:22 | <Philip`> | duryodhan: http://www.mozilla.org/projects/security/components/signed-scripts.html talks about Codebase Principals, which seems relevant here |
| 16:23 | duryodhan | wonders why chatzilla links didn't open in a new tab |
| 16:25 | <duryodhan> | Philip`: I am still reading but at a glance it seems my hunch was right , that signing scripts would then not require me to enable codebase_principal support |
| 16:36 | <Lachy> | duryodhan: if you want links in chatzilla to open a new tab, you need to middle click them |
| 16:36 | <duryodhan> | yeah |
| 16:36 | <duryodhan> | I realised that now |
| 16:37 | <duryodhan> | I thought It would act as if an outisde app is opening page |
| 16:37 | <duryodhan> | (and thus firefox owuld open it in a new tab/window according to my prefs ) |
| 16:38 | <Lachy> | yeah, it's a little unintuitive. It should follow that pref |
| 16:38 | <Lachy> | but it's not technically an external application |
| 16:38 | Philip` | uses the high-tech strategy of selecting text from IRC in the terminal window, copying, switching to a browser window, opening a new tab, pasting, adding the h at the beginning that usually got missed when selecting the address, then pressing enter |
| 16:41 | <Lachy> | Philip`: which IRC client are you using? |
| 16:42 | <Philip`> | Lachy: Irssi |
| 16:43 | <Lachy> | oh. I tried that, but gave up on it cause I couldn't click on links |
| 16:43 | <Philip`> | Oh :-) |
| 16:43 | <gavin_> | terminal.app lets me click on links when I use irssi :) |
| 16:44 | <Lachy> | I'm using chatzilla at the moment. I used to use xchat on my mac, but my mac is faulty and keeps freezing |
| 16:46 | Philip` | is just running in Konsole |
| 16:46 | <Philip`> | Ooh, Klipper helps - if I turn its 'actions' on, I can double-click a link and it pops up a little menu with options like "Open in Konqueror", "Open in Mozilla", "Open in Firefox" |
| 16:47 | <Philip`> | though somehow I've messed up Konqueror so when I try visiting a web site in it, it saves it to a temporary file and opens Opera instead |
| 17:03 | <h3h> | ugh, versioning revisited |
| 17:06 | <Philip`> | I don't really see why document validity should be a goal in itself |
| 17:06 | <h3h> | it shouldn't |
| 17:06 | <h3h> | it's help as a means to an end |
| 17:08 | <Philip`> | Then, I don't really see why someone would think document validity is a goal in itself (but it seems some do think that) |
| 20:40 | <othermaciej> | does anyone know where to find the latest editor's draft of xhtml2? |
| 20:40 | <othermaciej> | the most recent I could find is this: http://www.w3.org/MarkUp/2007/ED-xhtml2-20070402/ |
| 20:41 | <othermaciej> | I assume it is in w3c cvs somewhere though |
| 20:46 | <Hixie> | do people really think that "XHTML2 and XHTML5" is bad but "XHTML2 and XHTML1.5" is good? especially given the reality of the 5>2 thing? |
| 20:47 | <Hixie> | i'd have thought 1.5 would be more confusing for authors ("clearly XHTML2 is what i should be using, XHTML1.5 is not as new as XHTML2") |
| 20:50 | <othermaciej> | I personally don't care either way |
| 20:51 | <othermaciej> | the XHTML 2 WG seems to hate the idea of any use of the XHTML name |
| 20:51 | <Hixie> | yeah that's more of a problem |
| 20:54 | <Hixie> | as you say in e-mail, the namespace part is worse |
| 20:54 | <Hixie> | though i personally think it's a non-issue |
| 20:54 | <Hixie> | let them include a fatal flaw in their language |
| 20:54 | <Hixie> | it won't affect us in the slightest |
| 20:54 | <Hixie> | all it will do is guarentee nobody implements xhtml2 |
| 20:55 | <othermaciej> | I don't mind them using it |
| 20:55 | <othermaciej> | but they want us to change our namespace |
| 20:55 | <Hixie> | oh |
| 20:55 | <Hixie> | well |
| 20:55 | <othermaciej> | because XHTML2 is more compatible |
| 20:55 | <Hixie> | that's not even really up for debate |
| 20:55 | <Hixie> | i wouldn't pay that much mind |
| 20:55 | <Hixie> | there's no way tim would side with them on that |
| 20:56 | <Hixie> | i mean, even if by some fluke of reality distortion fields the htmlwg was forced not to use that namespace, i would just make the htmlwg spec not mention the namespace and let the whatwg one handle it |
| 20:56 | <Hixie> | it's not an issue |
| 20:57 | <othermaciej> | I don't think so either, that's why I think it is ok to ignore them and let the Director settle it if needed |
| 21:47 | <Hixie> | http://krijnhoetmer.nl/irc-logs/xhtml/20070530#l-172 |
| 21:48 | <jruderman> | why is safari's "view source" command disabled on that page? |
| 21:49 | <Hixie> | safari doesn't enable it until the page has finished loading |
| 21:52 | <jruderman> | it seems finished |
| 21:54 | <Hixie> | hm, i learn more about what the htmlwg is doing from the secretive chairs list than i do from the public list |
| 21:54 | <Hixie> | http://lists.w3.org/Archives/Member/w3c-html-cg/2007AprJun/0203.html |
| 21:55 | <Hixie> | that's sad |
| 21:57 | <Hixie> | hm, othermaciej was looking for a list of xhtml2 documents and their status, including latest editor's drafts, it seems that's here: http://www.w3.org/MarkUp/Drafts/Overview.html |
| 22:01 | <Philip`> | That makes it sound like the editor's drafts listed there are constantly updated to always be the latest version, but then it looks a bit odd that the latest XHTML2 one is two months old |
| 22:01 | <Philip`> | http://www.w3.org/MarkUp/Drafts/autoPublication.html is slightly sparse on the details, sadly :-( |
| 22:17 | <Hixie> | i think it's probably accurate that the draft hasn't been updated since april |
| 22:40 | <Hixie> | othermaciej: < Hixie>|hm, othermaciej was looking for a list of xhtml2 documents and their status, including latest |
| 22:40 | <Hixie> | editor's drafts, it seems that's here: http://www.w3.org/MarkUp/Drafts/Overview.html |
| 22:43 | <othermaciej> | Hixie: thanks |
| 22:43 | <othermaciej> | Hixie: I was wondering if they'd changed the namespace URI yet, it looks like not |
| 22:43 | <othermaciej> | Hixie: even though they have been saying for a long time that they don't have a different namespace |
| 23:17 | <Hixie> | christ, how hard can this versioning thing be |
| 23:18 | <Hixie> | right, afk, bbiab |