| 00:00 | <gsnedders> | s/is/are/ |
| 00:00 | <masinter> | midnight in CET? |
| 00:00 | <gsnedders> | midnight in BST at the moment |
| 00:00 | <mitnavn_> | It's 1AM here |
| 00:00 | <mitnavn_> | CET |
| 00:01 | <gsnedders> | mitnavn_: No, you're CEST :P |
| 00:01 | <mitnavn_> | True |
| 00:01 | <mitnavn_> | But is there anyone not switching? |
| 00:01 | gsnedders | blatantly needs to get onto saner living hours |
| 00:01 | <gsnedders> | mitnavn_: In CET? No. |
| 00:05 | <masinter> | i had a long discussion with Maciej about error handling in IRI processing, but it's not in th elog |
| 00:05 | <masinter> | well and Hixie, wonder what might have happened. |
| 00:05 | <gsnedders> | krijnh keeps on dying |
| 00:06 | <gsnedders> | If you (or anyone else can) email a copy of logs to krijn, then he can add them |
| 00:08 | <masinter> | i wish i'd kept it, it was a good case and relevant to the IRI spec |
| 00:09 | <annevk42> | masinter, several people here keep private logs; they should be able to help krijnh fix the logs |
| 00:10 | <masinter> | all discussions are destined to be repeated anyway, aren't they? |
| 00:10 | <annevk42> | well, there's that too :) |
| 00:10 | <masinter> | i think the case was about why it was a good idea not to specify precisely how illegal IRIs should be handled |
| 00:10 | <annevk42> | anyway, you were right about Europe, I need to fetch some sleep :) |
| 00:10 | <annevk42> | nn |
| 00:11 | <gsnedders> | nighty |
| 00:13 | <masinter> | if you have an IRI http://XXXZ/ where Z isn't a valid input to the punycode conversion algorithm, that it was good to say that the result should not result in a valid domain name in a URI, but leave it open whether the processor might signal an error or otherwise replace the domain name with something that was guaranteed not to be valid |
| 00:13 | <masinter> | signalling an error may be preferable in cases where you are, for example, doing resolution, but there are legitimate applications which cannot signal errors |
| 00:15 | <masinter> | back later |
| 03:03 | <GPHemsley> | annevk42: Are you aware that the "Changed attributes" section of html5-diff is not capitalized like the rest of the sections? |
| 06:23 | <masinter> | I'm trying to figure out about percent-encoding the query component of IRIs in browsers, and maybe it's late, but it seems there is no good normative advice to give if the percent-encoding is delayed until the query-IRI is interpreted |
| 06:24 | <masinter> | it would seem like asking browsers to percent-encode the form data using the document character set BEFORE the IRI (with query) is constructed would give more consistent results |
| 06:25 | <masinter> | at least in the case where the document character set isn't Unicode-based |
| 06:25 | <masinter> | browsers might have to change their behavior in constructing the IRI-with-query-added, but the results would be more consistent and fewer bugs, and it wouldn't affect interpretation of any existing web pages |
| 07:17 | <othermaciej> | masinter: what particular change do you have in mind relative to what was in the Web Address draft? |
| 07:21 | <othermaciej> | masinter: %-encoding the query part of the (pseudo)-IRI has to use the document encoding no matter where it comes from originally - it could be a result of form submission, or it could be present literally on the page as an href attribute, or it could be presented to an API such as assigning location |
| 07:21 | <othermaciej> | masinter: so it has to happen at the time you resolve the address (or at the time you convert it to a URI, if that is immediately after) |
| 07:21 | <othermaciej> | masinter: this means the rules have to diverge from processing as an IRI, unless the document encoding is UTF-8 |
| 07:33 | <Hixie> | othermaciej: did you ever end up sending those summaries of the telecons that you mentioned you were going to send? |
| 07:34 | <othermaciej> | Hixie: no, but I will start doing it this week |
| 07:35 | <othermaciej> | last time I chaired the telecon I had to get on a plane immediately after |
| 07:35 | <othermaciej> | I don't think anything important was overlooked though |
| 07:42 | <Hixie> | othermaciej: i couldn't tell from the last three meetings' minutes whether there was anything i needed to know about for the spec |
| 07:42 | <Hixie> | any new feedback, plans that would affect the spec, or whatever |
| 07:42 | <othermaciej> | Hixie: there was not |
| 07:43 | <othermaciej> | the topics involved checking on people's actions (which may someday have indirect influence on the spec), closing out tracker issues (which reduces the possibility of needing further changes), and creating task forces |
| 07:43 | <othermaciej> | in the most recent telecon we discussed the Origin header and I mentioned your plan to either replace it with Sec-From or remove it |
| 07:43 | <othermaciej> | (since the end of the month is closing in I'm assuming remove is more likely) |
| 07:46 | <Hixie> | k |
| 07:46 | <Hixie> | i wonder if i should create a some task forces to |
| 07:46 | <Hixie> | o |
| 07:48 | <Hixie> | maybe i should have a summary="" annihilation task force |
| 07:48 | <othermaciej> | if you feel that would be a valuable use of your time, be my guest |
| 07:49 | <Hixie> | we could have a t-shirts made, "improving accessibility by research instead of dogmatism" or something |
| 07:49 | <Hixie> | maybe something more pithy |
| 07:52 | <hsivonen> | wow. according to roc's blog, MS implemented an IE6 mode for their authoring tool without actually using IE6 |
| 07:53 | <hober> | Hixie: i7g a11y b0y r6h i5d o0f d7m |
| 08:14 | <jgraham> | hsivonen: Yeah. I'm glad I wasn't an engineer who went in one morning to be told "we want you to reimplement IE6. Yes, from scratch. No, with all the same quirks" |
| 08:19 | <masinter`> | missed some context here |
| 08:20 | <masinter`> | %-encoding the query part only has to use the document encoding when the pseudo-IRI is formed in the first place, rather than forming an IRI first and then %-encoding the result when trying to convert the IRI to URI (or, rather, URI-components) |
| 08:21 | <annevk42> | note that any input to the URL parsing algorithm is most likely UTF-16 and almost definitely Unicode based |
| 08:22 | <masinter`> | not sure how that's relevant, but sure |
| 08:22 | <annevk42> | well, you mentioned earlier about percent-encoding according to the relevant character earlier; I'm just saying that's not what's happening now |
| 08:22 | <masinter`> | i didn't think it was what was happening now |
| 08:23 | <annevk42> | ah right, you suggested it could be changed? |
| 08:23 | <masinter`> | what's happening now is a mess, inconsistent, and fragile |
| 08:24 | <annevk42> | it's highly unlikely that what I described in my first sentence will change |
| 08:24 | <masinter`> | yes, to propose that normative correct behavior for constructing pseudo-IRIs based on form submission should do the percent-encoding at the time the pseudo-IRI is constructed |
| 08:25 | <annevk42> | but maybe I just don't understand what you're proposing since I'm not familiar with pseudo-IRIs and such |
| 08:25 | <masinter`> | in the special case of http URIs and when the document character encoding isn't UTF-8 or UTF-16 |
| 08:25 | <masinter`> | well, say you have a form in a a page that is ISO-8859-1 |
| 08:25 | <GPHemsley> | annevk42: Did you get my message earlier? |
| 08:25 | <masinter`> | and you click submit on the form, and some of the form data is typed in, not in ASCII |
| 08:26 | <masinter`> | and it constructs an IRI and then interprets the IRI |
| 08:26 | <annevk42> | GPHemsley, yes |
| 08:26 | <GPHemsley> | k |
| 08:26 | <annevk42> | GPHemsley, can't really fix it now, but will do hopefully later |
| 08:26 | <masinter`> | the form construction and IRI interpretation happens all during the uesr interaction |
| 08:26 | <GPHemsley> | annevk42: Sounds good |
| 08:26 | <masinter`> | the IRI may be available to scripting? I'm not sure |
| 08:27 | <masinter`> | pseudo-IRI constructed as a result of form processing |
| 08:27 | <annevk42> | not the URI, but the things the user has typed in will be |
| 08:27 | <masinter`> | huh? |
| 08:27 | <annevk42> | and what the user has typed in will be encoded as UTF-16 or some such typically |
| 08:27 | <annevk42> | masinter, what the user types in is exposed to script |
| 08:28 | <masinter`> | before the pseudo-IRI is constructed |
| 08:28 | <annevk42> | the URL is constructed at submission, so yes |
| 08:28 | <masinter`> | but at some point an IRI is constructed from the user input |
| 08:29 | <masinter`> | currently the IRI is constructed by using the unicode of the input directly |
| 08:30 | <masinter`> | and the burden is on the IRI interpretation to then percent-encode the result by remembering the document character set of the origin of the IRI |
| 08:30 | <annevk42> | well, it's an input to the resolving algorithm |
| 08:31 | <masinter`> | the IRI could be constructed by percent-encoding the form data in the query part, using the IRI's associated character encoding at the time of constructing the IRI |
| 08:32 | <masinter`> | this IRI is never stored because it's passed directly to IRI resolution |
| 08:32 | <annevk42> | if you can figure out the query part while not properly parsing the URL I suppose you can do that |
| 08:34 | <masinter`> | the query part is constructed, not 'figured out' |
| 08:34 | <masinter`> | if you mean 'parsed and interpreted' as figuring out |
| 08:37 | <masinter`> | i'll be back in the morning |
| 08:46 | <masinter`> | new version of iri 'fork' document for beating up http://larry.masinter.net/iribis-hack.html |
| 08:55 | <Hixie> | that doesn't seem to be anything like what webaddresses did, unless i'm missing something |
| 08:57 | <Hixie> | where's the definition of how to resolve a url given another url with, e.g. the encoding changing from utf-16 to utf-8, and the document base address having an effect, and backslashes being changed to slashes, etc? |
| 08:57 | <Hixie> | also missing seems to be the algorithm for parsing an arbitrary strings into components |
| 08:57 | <Hixie> | unless again i'm missing something |
| 08:57 | <Hixie> | also it seems to be contrary to the goals of the effort to have these rules be in a separate section... shouldn't they just be the rules that apply to all UAs? |
| 08:57 | <Hixie> | surely we don't want different UAs doing different things |
| 09:02 | <Hixie> | it also seems to lack a definition of "absolute url" that works for invalid iris |
| 09:04 | <masinter`> | i think you're missing something |
| 09:05 | <masinter`> | the backslash question is listed as an issue |
| 09:05 | <Philip`> | Is there an online version of HTML5 that defines the details of what the document base URL is? |
| 09:05 | <masinter`> | the goal of this document is not to provide a line-for-line replacement for the webaddress document |
| 09:05 | <Hixie> | oh |
| 09:06 | <Hixie> | that could be a problem |
| 09:06 | <masinter`> | it's to fix IRIs so that HTML can make a normative reference to it |
| 09:06 | <Hixie> | since that's what i'm looking for :-) |
| 09:06 | <Hixie> | well whatever happens i need the following: |
| 09:07 | <masinter`> | the goal is to allow a definition of IRI that doesn't need overriding or a willful violation |
| 09:07 | Philip` | finds it in http://www.w3.org/TR/2009/WD-html5-20090423/ |
| 09:08 | <masinter`> | and to get IDNA and the IRI folks to agree to the changes necessary |
| 09:08 | <masinter`> | so IDNA needs to bless it, as well as Martin and Roy |
| 09:08 | <Hixie> | * a definition of a valid IRI that handles encodings other than UTF-8 (e.g. saying that in non-UTF-8 contexts, the query needs to not be non-ASCII) |
| 09:08 | <masinter`> | IRIs aren't defined in terms of encodings |
| 09:08 | <masinter`> | an IRI is a sequence of characters, not of octets |
| 09:08 | <Hixie> | * a definition of absolute IRI that handles having invalid strings be absolute, e.g. http://www.example.com/%X being an "absolute IRI" |
| 09:08 | <masinter`> | single percent was added to the IRI bnf |
| 09:09 | <masinter`> | and whether something is absolute or relative should be determined by whether there's a scheme |
| 09:09 | <masinter`> | but whether something is a 'valid IRI' will be narrower than what browsers do |
| 09:09 | <Hixie> | * an algorithm that defines how to take an arbitrary string (including one that isn't a valid IRI of any form) and get out the scheme, host, port, hostport, path, query, fragment, and host-specific (as those were defined in [WEBADDRESSES]) |
| 09:10 | <masinter`> | the algorithm for getting out those parts are in the document |
| 09:10 | <masinter`> | section 3.2 |
| 09:10 | <Hixie> | * an algorithm that takes an arbitrary string, an encoding, and an absolute IRI (as defined above) and returns an absolute IRI |
| 09:11 | <masinter`> | the specification of a protocol element can be done by providing syntax and processing rules without using an algorithm |
| 09:11 | <Hixie> | * the algorithm to get the document Web base address, again as in [WEBADDRESSES] |
| 09:11 | <Hixie> | ...and where all these algorithms are such that the browser vendors are willing to implement them exactly, with no deviations whatsoever |
| 09:11 | <masinter`> | the document web base address is a feature of the language in which the IRI is embedded and the method of retrieving it, not a feature of the IRI itself |
| 09:12 | <masinter`> | I know more than this document is needed |
| 09:13 | <masinter`> | but getting at least the terminology and direction is a prerequisite to not having IRIs in web browsers work differently or be spec'd differently than IRIs in email, voice over IP, instant messaging, newsfeeds, and all of the other standards that need IRIs |
| 09:13 | <Hixie> | what is section 7 for then? |
| 09:14 | <masinter`> | you don't think section 7 is useful? |
| 09:14 | <masinter`> | what part of section 7 do you object to? |
| 09:14 | <masinter`> | section 1.3 contains terms that refer to section 7 |
| 09:14 | <Hixie> | well it seems like if the goal is to just make IRIs work properly and interoperably, section 7 would presumably not need to exist |
| 09:14 | <hsivonen> | masinter`: speaking of section 7, section 7 of the current IRI RFC is marked as informative but uses "should". That's confusing. |
| 09:15 | <masinter`> | hmm, lots of documents have a section 7, but why should section 7 of the current IRI RFC have anything to do with section 7 of this rewrite of Martin's internet draft? |
| 09:15 | masinter` | wonders if the HTML5 document has a section 7 |
| 09:16 | <masinter`> | the document contains an extensive writeup of the goals |
| 09:16 | <masinter`> | section 12 lists the goals |
| 09:17 | <masinter`> | Maciej had some comments on the goals as I originally posted them, which I tried to incorporate or address |
| 09:18 | <Hixie> | i don't really understand section 3.2. What parts of it are normative? I don't see any RFC2119 terms, and it's not clear to me what "parse" means in this context |
| 09:18 | <Hixie> | parse how? |
| 09:19 | <Hixie> | does it mean "try to match the string against the abnf"? if so, against which production? |
| 09:19 | <Hixie> | surely the parsing of a URI shouldn't be based on scheme-specific rules? that would mean that the same URL would parse different based on whether the UA knew the scheme or not |
| 09:21 | <Hixie> | as a general comment, this is a difficult draft to follow. It's not clear for example where the HTML5 spec should hook in and how to follow from that entry point (wherever it is) to the nitty gritty with the "must" requirements for actually parsing something |
| 09:21 | <masinter`> | i need to patch in more of RFC 3986 |
| 09:21 | <masinter`> | the major surgery was to move from "map IRI to URI and then parse according to RFC 3986 using greedy parsing" to "parse first, then map if you need to" |
| 09:22 | <masinter`> | but i need to pull in more of the RFC 3986 definition of what normative parsing is |
| 09:22 | <masinter`> | good catch |
| 09:23 | <masinter`> | the document with through lots of revisions with lots of comments from lots of groups, i agree it's hard to follow |
| 09:23 | <masinter`> | i did more surgery than martin is comfortable with, and wound up rewriting or rewording big chunks for clarity, but it needs a lot more |
| 09:24 | <hsivonen> | masinter`: I'm just whining about the standing IRI RFC. |
| 09:24 | <masinter`> | and i agree that hooking this into the HTML5 spec is some work, but frankly, even though this document has problems, some of the difficulty is certainly due to the structure of the HTML5 spec |
| 09:25 | <hsivonen> | masinter`: "section 7" together with "IRI" reminded me |
| 09:25 | <masinter`> | i only worked on the first 9 versions of it, and Martin and Michel did the other 10 versions, so i blame them for all of the RFC's problems |
| 09:26 | <hsivonen> | masinter`: I hope the bug of using "should" in an informative section gets fixed in bis (I haven't checked if it has been fixed already) |
| 09:26 | <masinter`> | Martin and Michel did the first 5 versions of this document and I'm only on my second pass |
| 09:26 | <masinter`> | i think i got that one, but i'm sure there are tons of problems left |
| 09:27 | <masinter`> | this isn't going to get out of IETF until IDNA gets agreement on it |
| 09:27 | <Hixie> | masinter`: if there's anything i can do to make hooking html5 into it easier, let me know |
| 09:28 | <masinter`> | we probably should sort out the requirements and see if there's agreement on "what belongs in IRI/URI and what belongs in HTML" |
| 09:28 | <masinter`> | and see if we can get Fielding & Duerst & Klensin to go along |
| 09:29 | <masinter`> | and Vint said he would help with the IDNA coordination |
| 09:30 | <masinter`> | we probably need to update mailto: also |
| 09:30 | <masinter`> | and there might be changes needed to http URI |
| 09:30 | <masinter`> | isn't it common for browsers to have an option to send uTF8 paths? |
| 09:31 | <masinter`> | the previous method of converting from IRI to URI generically, parsing, and then selectively converting back to IRI basically is broken, it is likely information-lossy in some important cases |
| 09:32 | <masinter`> | so this draft at least turns IRI handling into something resembling what browsers do which is to parse first |
| 09:36 | <masinter`> | hsivonen: people try to be sticklers about MUST, MAY, SHOULD, but the notion of separating "Normative" from "Informative" isn't always followed in IETF documents, so reviewers might not notice it as much |
| 09:37 | <masinter`> | For me, the main thing is to make sure that you can really identify what it means to "implement" a "feature" and link that to normative requirements |
| 09:37 | <masinter`> | so that "interoperable implementations of every feature" means something |
| 09:37 | <masinter`> | http://larry.masinter.net/draft-ietf-newtrk-interop-reports-00.html |
| 09:40 | <masinter`> | Peter Saint-Andre actually tried to do that for XMPP (Jabber), http://xmpp.org/internet-drafts/draft-saintandre-xmpp-interop-report-00.html |
| 09:40 | <masinter`> | it would be interesting to look at HTML and think about what the "protocol feature set" would look like, and which of the normative requirements have anything to do with anything that could be tested. |
| 09:44 | masinter` | needs to sleep, will check back later |
| 09:44 | Philip` | likes being able to link feature tests to normative requirements |
| 09:45 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/results.html tries to do that and is mostly successful |
| 09:54 | <AryehGregor> | Broken link: http://wiki.whatwg.org/wiki/FAQ#When_will_we_be_able_to_start_using_these_new_features.3F |
| 09:55 | <AryehGregor> | Hmm. |
| 09:55 | <AryehGregor> | Is it? |
| 09:55 | <AryehGregor> | Yeah . . . |
| 09:56 | <Philip`> | "namespace deceleration attributes" - quick, don't let those speeding namespaces get away! |
| 09:56 | <AryehGregor> | Ah, there we go: http://wiki.whatwg.org/index.php?title=FAQ&diff=4024&oldid=3992 |
| 10:23 | <EruditeHermit> | hi |
| 10:24 | <EruditeHermit> | can anyone help me with the video tag? |
| 10:24 | <EruditeHermit> | when I try to do width and height by %, It leaves a huge gap between the video and the controls |
| 10:24 | <EruditeHermit> | and it also leaves a huge gap between the above element and the video |
| 10:24 | <AryehGregor> | What exact code are you using, in which browser? |
| 10:24 | <EruditeHermit> | firefox |
| 10:25 | <EruditeHermit> | 3.5 |
| 10:26 | <EruditeHermit> | http://pastebin.com/m6eb15836 |
| 10:28 | <AryehGregor> | The width and height attributes don't accept percentage values, AFAICT. They're pixel values. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width |
| 10:29 | <AryehGregor> | Also, the align attribute doesn't work on <video>. |
| 10:29 | <AryehGregor> | You need to use CSS. |
| 10:29 | <AryehGregor> | Do percentage widths and heights even work on <img>? |
| 10:29 | <EruditeHermit> | if I do style="width height align etc does it work? |
| 10:29 | <EruditeHermit> | I get the same problem using css height and width in percentages |
| 10:31 | <AryehGregor> | Can you get the desired sizing with <img> or any other HTML element, or is this really specific to <video>? |
| 10:31 | <EruditeHermit> | I can get the desired sizing with div |
| 10:31 | <EruditeHermit> | let me try img |
| 10:32 | <EruditeHermit> | yeah img works fine |
| 10:33 | <AryehGregor> | I'm not sure of the answer offhand, sorry. Maybe someone else will be able to answer. |
| 10:33 | <mookid> | you know |
| 10:33 | <mookid> | this still realy pisses me off |
| 10:34 | <mookid> | [13:31] <Hixie> yes but HTTP conneg, as previously discussed, is a bad idea |
| 10:34 | <mookid> | and that was almost a year ago |
| 10:34 | <Philip`> | That should have been plenty of time to calm down and accept the notion |
| 10:35 | <mookid> | it's a bullshit notion made by an ignorant fool |
| 10:35 | <mookid> | so no. |
| 10:35 | <mookid> | :) |
| 10:36 | <Philip`> | EruditeHermit: Is the desire for it to be 70% of the screen size? |
| 10:37 | <EruditeHermit> | yes |
| 10:37 | <EruditeHermit> | well 70% of the size of the container div |
| 10:38 | <EruditeHermit> | but that it will fit on a screen is my goal |
| 10:38 | <EruditeHermit> | so I want to use % |
| 10:40 | <Philip`> | EruditeHermit: Hmm, I'm not sure how CSS sizing is meant to interact with <video width height> |
| 10:40 | <Philip`> | I'd expect the CSS to be the same as for div/img/etc, but I have no idea how it'd be rendered |
| 10:41 | <EruditeHermit> | I don't want to specify pixel height and width because screens are so different these days |
| 10:45 | <AryehGregor> | EruditeHermit, <video style="width: 70%; height: 70%"> doesn't work? |
| 10:45 | <EruditeHermit> | it makes it smaller yes |
| 10:45 | <EruditeHermit> | but it leaves a huge gap between the element above and the video |
| 10:45 | <EruditeHermit> | and also if you have controls |
| 10:45 | <EruditeHermit> | there is a huge gap between the controls and the bottom of the video |
| 10:47 | <mookid> | ok hold on a second |
| 10:48 | <mookid> | Philip`: where does "URL decomposition IDL attributes" come from? |
| 10:49 | <Philip`> | mookid: Why should I know that? |
| 10:50 | <Philip`> | mookid: Anyway, I'd suggest trying http://whatwg.org/html5#url-decomposition-idl-attributes |
| 10:50 | <mookid> | no idea, sorry - trying to work out where a URL was decided to have a 'query' component |
| 10:51 | <Philip`> | (Definitions and headings get ids that are lowercased hyphenated strings, so they're usually easy to find that way) |
| 10:51 | <AryehGregor> | EruditeHermit, do you have a publicly-accessible page to look at, maybe? |
| 10:51 | <AryehGregor> | (although I have to go in a few minutes) |
| 10:51 | <AryehGregor> | I can't tell what's wrong from looking at the markup. |
| 10:53 | <EruditeHermit> | hmm |
| 10:54 | <EruditeHermit> | not sure I can do that in a few minutes |
| 10:54 | <EruditeHermit> | let me try though |
| 10:55 | <AryehGregor> | Maybe someone else can help when I leave. |
| 10:55 | <AryehGregor> | Good luck, anyway. |
| 10:55 | <EruditeHermit> | thanks |
| 10:55 | <EruditeHermit> | maybe i'll catch you tomorrow or something |
| 10:55 | <EruditeHermit> | how long before you leave? |
| 10:56 | <mookid> | Philip`: thanks I found the RFC I was looking for |
| 10:56 | <AryehGregor> | Um, I should be leaving now, actually. |
| 10:56 | <EruditeHermit> | ok |
| 10:57 | <EruditeHermit> | AryehGregor, thanks for helpingme |
| 11:15 | <krijn> | http://www.quirksmode.org/blog/archives/2009/09/the_html5_drag.html |
| 11:16 | <pesla> | </rant> |
| 11:17 | Hixie | commented already |
| 11:22 | <Philip`> | He seems to have a peculiarly strong reaction to the need to write two lines of code to disable some events |
| 11:23 | <NetBen> | and he's right.. |
| 11:24 | <Hixie> | yeah it is a pretty horrible api |
| 11:24 | <Hixie> | but i'm sure none of the people arguing in favour of decentralised extensibility will learn the same lesson from this as i did... |
| 11:25 | <NetBen> | name calling here and there is a bit... meh tho |
| 11:32 | <Lachy> | if you ignore the unnecessary swearing and insults, he does appear to make some valid points about it. |
| 11:33 | <Lachy> | it's a shame there's not much we can do about it without breaking compat |
| 11:33 | <jgraham> | If only praise for _not_ doing work was always this forthcoming |
| 11:34 | <Lachy> | jgraham, that praise won't last long if Opera decides to implement the API soon |
| 11:35 | <Lachy> | but I'm not sure how essential it is. I'm not aware of any sites that actually use it. Though, I assume there must be some, given that Firefox and Safari were motivated to implement it. |
| 11:42 | <jgraham> | Lachy: I wasn't being quite serious :) |
| 11:43 | <jgraham> | If no sites actually use it, why do we need IE compatibility? |
| 11:43 | <jgraham> | Are we assuming that they don't want to implement two D&D APIs? |
| 11:43 | <jgraham> | Has anyone asked them to copnfirm this? |
| 11:43 | <jgraham> | *confirm |
| 11:44 | <krijn> | Why not use something like Scriptaculous or jQuery UI as a baseline? |
| 11:46 | <jgraham> | krijn: Those APIs aren't obviously very DOM-like are they? |
| 11:46 | <krijn> | Why not? |
| 11:47 | <zcorpan> | if ie crashes when you try to use the api, it seems like it would degrade better in ie if it was a new incompatible api |
| 11:48 | <krijn> | Something like http://jqueryui.com/demos/draggable/, natively, would be awesome |
| 11:49 | <NetBen> | well as it currently is, people will use js frameworks for D&D, compat is not an issue |
| 11:49 | <krijn> | Agreed |
| 11:50 | <krijn> | So it's probably something for JS libs to implement |
| 11:50 | <krijn> | Why don't they use the native APIs in browsers that support it? |
| 11:50 | <krijn> | JohnResig? :) |
| 11:50 | <jgraham> | krijn: For example the DOM is typically event based rather than callback based |
| 11:51 | <jgraham> | Even though callback-based stuff is arguably a better fit for ecmascript |
| 11:51 | <NetBen> | ah, we need to differentiate between api and the way it's implemented |
| 11:51 | <krijn> | jgraham: UI is event based as well |
| 11:51 | <krijn> | (Mostly) |
| 11:51 | <krijn> | (Or I don't get your point :) |
| 11:53 | <jgraham> | krijn: I was just looking at the example element.draggable({"start":callback}) |
| 11:53 | <jgraham> | which seems nice but not very DOM-like |
| 11:53 | <krijn> | Then create an ondragstart thingy for that |
| 11:53 | <NetBen> | addEventListener("dragstart", callback) |
| 11:54 | <jgraham> | krijn: Right, at which point you no longer have the jQuery-ui API |
| 11:54 | <krijn> | (Although there is already one like that ;) |
| 11:54 | <jgraham> | I agree that if we were to redesign this it would be good to take inspiration from js libaries and ensure that the'r functionaility could be replicated using the native api |
| 11:55 | <NetBen> | the troubs with the API is how the events work (or dont work) and some events being redundant, methods isn't really the issue I believe |
| 11:55 | <jgraham> | *their |
| 11:55 | <Philip`> | So you'd want to copy the concepts from JS libraries, but not the syntax? |
| 11:56 | <NetBen> | exactly |
| 11:56 | <NetBen> | and not really the concepts either actually, just the derived logic on how people actually use drag and drop |
| 11:57 | <krijn> | Yeah, JS libs can build wrappers/syntaxes around it |
| 11:57 | <NetBen> | instead of something that got obviously lost in outdated specs written in a time when bad practises where common and no one really had a clue on web |
| 11:57 | <NetBen> | standards |
| 11:57 | <NetBen> | I assume |
| 11:59 | <jgraham> | The IE API was never a standard. It was reverse engineered for HTML5 at a time when it was asssumed that IE would not put significant effort into HTML5 support |
| 11:59 | <NetBen> | so the spec is reverse enginered from IE specs? |
| 11:59 | <NetBen> | for compatibility? |
| 11:59 | <jgraham> | From IE behaviour |
| 12:00 | <jgraham> | for IE6 compatibility |
| 12:00 | <jgraham> | Which is still an argument in favour of the current spec but maybe a weaker one than it was in 2004 |
| 12:01 | <Philip`> | Presumably there should still be a spec that says something compatible with existing content |
| 12:01 | <krijn> | Perhaps we need data about how much this API is used on the web? :) |
| 12:01 | <NetBen> | ok, chances of this spec actually being used in RL is? |
| 12:02 | <Philip`> | (though it might say nothing, if there's no existing content worth worrying about) |
| 12:02 | <jgraham> | Oh everyone else just said that |
| 12:02 | <NetBen> | =P |
| 12:02 | <NetBen> | WhatWG != WhatWH |
| 12:02 | <NetBen> | hopefully =P |
| 12:04 | <Lachy> | NetBen, what does "WhatWH" stand for? |
| 12:04 | <NetBen> | What we have |
| 12:04 | <Lachy> | oh |
| 12:04 | <Philip`> | Millions of people use stuff like <body ondragstart="return false"> it seems |
| 12:05 | <jgraham> | Philip`: Is that to stop people "stealing" content? |
| 12:05 | <Philip`> | Not sure how many rely on it for important behaviour |
| 12:05 | <NetBen> | and it can stay that way np |
| 12:05 | <Philip`> | <body leftmargin="0" topmargin="0" marginwidth="0" marginheight="0" oncontextmenu="return false" ondragstart="return false" onselectstart ="return false" onselect="document.selection.empty()" oncopy="document.selection.empty()" onbeforecopy="return false" onmouseup="document.selection.empty()"> |
| 12:06 | <Philip`> | jgraham: Looks like it might be, in most cases |
| 12:06 | <krijn> | I use that all the time |
| 12:06 | <krijn> | Clients want me to! |
| 12:06 | <krijn> | :) |
| 12:06 | <NetBen> | just say no... |
| 12:06 | <Philip`> | (That was from a .gov.cn site) |
| 12:08 | <Philip`> | krijn: I guess showing the clients how trivial it is to disable scripting in one's browser and freely copy text would just result in them telling you to turn all the text into images |
| 12:08 | <krijn> | (I wasn't serious, btw) |
| 12:10 | <Philip`> | Good, but clearly there's other people who want to prevent copying and other people who implement it :-( |
| 12:10 | <NetBen> | sounds like a good salespitch to sell pdf's |
| 12:11 | <Philip`> | What if they know about Acrobat's text selection tool? |
| 12:12 | <Philip`> | Hmm, I suppose PDFs probably support some flag to disable text selection |
| 12:12 | <NetBen> | basicly, you cant protect content |
| 12:12 | <NetBen> | then you have image to text translators |
| 12:12 | <gsnedders> | Make your content a huge CAPTCHA! |
| 12:13 | <Philip`> | so: What if they know about KPDF's "Obey DRM limitations" checkbox in its option dialog box? |
| 12:13 | <NetBen> | captcha has been broken already... |
| 12:13 | <krijn> | They should use WG telcons to spread their information! |
| 12:13 | <Lachy> | Philip`, that sounds like a preference that every use would obviously choose to leave enabled! :-) |
| 12:13 | <Philip`> | gsnedders: That would be excellent |
| 12:14 | <Philip`> | Lachy: I expect most will, since it's enabled by default and it very rarely prevents users doing what they want |
| 12:14 | <Philip`> | so they have no reason to change it |
| 12:15 | <Philip`> | I think I only ever found one PDF where it was an issue |
| 12:15 | <Lachy> | is that because most PDFs don't bother with DRM? |
| 12:15 | <Philip`> | Yeah |
| 12:15 | <Philip`> | or at least most PDFs that I ever look at |
| 12:15 | jgraham | tries email the list about the D^D API |
| 12:15 | <jgraham> | D&D, even |
| 12:16 | <jgraham> | silly swedish keyboard |
| 12:22 | <Mrmil> | Hi all, I have to ask, which one is more correct? <kbd>Alt</kbd> + <kbd>Shift</kbd> + <kbd>1</kbd> _or_ <kbd>Alt + Shift + 1</kbd> _or_ <kbd>Alt Shift 1</kbd>? |
| 12:28 | <Philip`> | Mrmil: The third seems wrong to me because the page should display the '+' characters to make it clear the keys are all pressed together |
| 12:29 | <Philip`> | The second seems wrong to me because it's ambiguous whether the + is meant to be a key just like all the others |
| 12:30 | <Philip`> | so if you had e.g. an Alt plus '+' key combination, the markup and presentation wouldn't distinguish them at all |
| 12:30 | <Philip`> | so the first seems more correct |
| 12:30 | <Philip`> | The HTML5 spec suggests <kbd><kbd>Alt</kbd> + ...</kbd> which seems more correcter since the whole thing is still marked up as keyboard input |
| 12:31 | <Philip`> | and then you can style the individual keys differently |
| 12:31 | <Mrmil> | I'm looking at it, looks probably like the most correct of all I mentioned above. |
| 12:34 | <Mrmil> | Who/what can actually use this information? |
| 12:35 | <Philip`> | CSS can style it in a visually distinctive way |
| 12:37 | <Mrmil> | Hm, thought there would be a better use for that... |
| 12:38 | <Philip`> | (Hmm, I vaguely remember seeing an example which used nested <kbd>s to draw little keyboard-like grey rectangles around keys, but I can't find it anywhere now...) |
| 12:39 | <Mrmil> | Well I do that, so now I'll have to change my styles because I'll have nested kbd's = nested rectangles :) |
| 12:41 | <Philip`> | Mrmil: The information conveyed by inline semantic elements seems to be very rarely used for anything other than styling, and <kbd> is of extremely limited relevance compared to most other elements so I wouldn't expect anyone to bother doing anything interesting with it |
| 12:42 | <Mrmil> | I see, thanks for feedback :) |
| 12:42 | <Philip`> | (It's only in HTML5 because some people use it (for the styling effect) and it's not actively harmful so there's no point getting rid of it, rather than because it's actually a valuable feature) |
| 12:42 | <zcorpan> | Mrmil: Alt+Shift+1 is correct |
| 12:44 | <Mrmil> | Philip`: Definitelly shorter than <span class="key">Alt</span>... |
| 12:44 | <Philip`> | Mrmil: But longer than <tt>Alt</tt>, and longer than Alt |
| 12:45 | <Mrmil> | :) |
| 12:45 | <Philip`> | Oh, HTML5 doesn't allow <tt> :-( |
| 12:45 | <Philip`> | Not much shorter than <code>Alt</code> then, if you want that default rendering |
| 13:01 | <Mrmil> | The HTML5 spec is so much better than XHTML 1.0 spec. (For a find-some-usage-info-about-this-tag person.) |
| 13:06 | <Lachy> | Mrmil, that's because the XHTML1 spec is just a delta spec. All the element definitions remained as is in HTML4 |
| 13:07 | <Mrmil> | Lachy: Hm. :) |
| 13:13 | <Mrmil> | They could at least show something like this http://www.w3.org/TR/xhtml11/doctype.html#s_doctype. If they did, though, it is burried somewhere where no-one can find it... |
| 13:13 | jgraham | notices he splet Philip's name wrong |
| 13:14 | jgraham | apologises |
| 13:59 | <Philip`> | jgraham: Oh, I didn't notice |
| 17:12 | <hsivonen> | grr. defer scripts effectively make eof like </script> only more complex |
| 17:22 | hsivonen | wonders why IE8 on Windows 7 Enterprise claims to be "Media Center" and "Tablet" |
| 17:22 | hsivonen | also wonders what OfficeLivePatch is |
| 17:29 | <brucel> | Hi crazy WHATWG types |
| 17:29 | <gsnedders> | brucel: How are you in the freezing west? |
| 17:30 | gsnedders | realizes he had misremembered |
| 17:31 | <brucel> | Am still west of sweden, gsnedders. |
| 17:32 | <gsnedders> | brucel: But I'm not in Sweden :P |
| 17:32 | <brucel> | So, Dear Cabal: I got emailed a request for html5 doctor for a simple guide to the new content types now block-level, inline are gone and we have a whole host of others. |
| 17:33 | <brucel> | Is there a simple guide to what they are and what they mean anywhere? |
| 17:33 | <gsnedders> | flow is basically the same as it was in HTML 4.01 Trans, i.e., block or inline |
| 17:35 | <gsnedders> | phrasing content is basically inline |
| 17:36 | gsnedders | realizes he sucks at really explaining this… |
| 17:45 | <brucel> | gsnedders I tried to explain it. and reaslied i suck at explaining it |
| 18:53 | masinter` | missed discussion about copy protection |
| 19:46 | <masinter> | I don't understand how Rowat links the complexity of the spec to difficulties for authors |
| 19:46 | <masinter> | the weakness of authoring conformance requirements makes it hard to figure out what really is or isn't a good idea |
| 19:47 | <masinter> | and there aren't guidelines for how to be compatible with deployed browsers as well as new ones |
| 19:47 | <masinter> | but those guidelines can be written, although most technical language specifications for a 'new version' of something often contain such guidelines directly |
| 19:48 | <masinter> | the main problem is that a complex spec adds an enormous burden for implementors, especially for consumers of HTML; producers can just ignore the parts they don't care about |
| 19:49 | <masinter> | talking about this on the mailing list isn't too effective -- mailing list is just filled with posturing |
| 19:49 | <Hixie> | hsivonen: wait, didn't we make it so document.write() always blows away the document in defer=""ed scripts? |
| 19:54 | <hsivonen> | Hixie: didn't you agree to change that per sicking's feedback? |
| 19:54 | hsivonen | doesn't remember |
| 19:56 | <gsnedders> | masinter: It's hard to simplify the implementer stuff without hurting web compat., as far as I can tell, though. |
| 19:58 | <Hixie> | hsivonen: we ended up changing something simpler, namely that defer="" doesn't apply to inline scripts |
| 19:59 | <hsivonen> | Hixie: oh ok. |
| 19:59 | <Hixie> | same lovely compatibility goodness, and half the transfats |
| 19:59 | <masinter> | i think we've gone around this several times, including two days ago, but i'll try once more. "web compat." is a stalking horse for a lot of things that are unrelated |
| 19:59 | <gsnedders> | (Also, I find CSS 2.1 much harder to understand what the expected rendering is.) |
| 20:00 | <gsnedders> | masinter: Well it's mainly a question of _how_ you simplify it |
| 20:00 | <masinter> | there's compatibility with existing content, with the main dominant browser (IE), with other existing browsers, with existing creation tools, with existing analysis tools, with search engines |
| 20:01 | <Hixie> | masinter: hsivonen and i mean the same thing by it, so it's ok :-) |
| 20:01 | <masinter> | and with what current browser development teams are willing to agree to implement. |
| 20:01 | <masinter> | hmmm |
| 20:02 | masinter | tries to remember if tweedledee and tweedledum are humpty-dumpty twins |
| 20:02 | <gsnedders> | masinter: with existing content is more or less the same as with the main dominant browser, and existing creation tools mainly have existing content |
| 20:02 | <masinter> | no, existing content *could* work with many different implementations |
| 20:03 | <gsnedders> | It could. But how much existing content does not work with the dominant browser? How much relies upon specific behaviour that only exists in the dominant browser? |
| 20:03 | <masinter> | you have a narrow interpretation of "work with" which is taken as "works exactly the same as", which may not be the same as "the author and the reader have a satisfactory communication experience" |
| 20:04 | <masinter> | which leads you to a narrow interpretation of "specific behavior" |
| 20:04 | <masinter> | Maciej had an interesting discussion about error behavior for IRIs when they contain, for example, illegal characters |
| 20:05 | <gsnedders> | Where do you draw the line between the two, though? |
| 20:05 | <masinter> | "two"? |
| 20:05 | <tantek> | masinter - perhaps you could add an entry about "What does 'web compat' mean?" to the WHATWG FAQ: http://wiki.whatwg.org/wiki/FAQ documenting the issues/ambiguities in the expression. |
| 20:05 | <tantek> | (that you've expressed) |
| 20:05 | <gsnedders> | "work exactly the same as" and "the author and the reader have a satisfactory communication experience" |
| 20:05 | masinter | tries to find something there is two of |
| 20:06 | <masinter> | I wrote about what I thought "interoperability" should mean in http://tools.ietf.org/html/draft-ietf-newtrk-interop-reports-00 |
| 20:06 | <gsnedders> | I wouldn't say we had to create an identical DOM as IE, but I wouldn't say we could come up with a DOM that made deployed scripts (that currently work in UAs with only tree-shaped DOMs) not work any more, for example |
| 20:07 | <masinter> | it's especially risky when you rely on black-box reverse engineering rather than open-box examination, because it's easy to infer the wrong generalization of behavior |
| 20:08 | <masinter> | for example, whether query strings are encoded using the document charset or using UTF8, the answer was different for mailto: |
| 20:08 | <gsnedders> | We can't do anything else but that for the dominant UA, and when sites rely upon behaviour only present there, what choice do we have? |
| 20:09 | <hsivonen> | masinter: you can open-box examine Gecko and WebKit |
| 20:09 | <gsnedders> | I agree it's suboptimal, but this is the world we're in. |
| 20:09 | <masinter> | when was the last time you tried actually asking MS what IE does, rather than relying on reverse engineering of what IE does? |
| 20:10 | <masinter> | and why do people say "the dominant browser" rather than IE, like IE was some dirty word? |
| 20:10 | <hsivonen> | masinter: maybe we should ask MS more often |
| 20:10 | masinter | dares to speak the name of "Internet Explorer", shaking down the building |
| 20:11 | <hsivonen> | masinter: in my experience about mode sniffing, though, one shouldn't just trust MSDN for instance, but one should always test the hypothesis, too |
| 20:11 | <gsnedders> | It's something that has been done in the past, and more or less there's either been no response or, "I'm asking for permission to publish that…" and then nothing more ever coming out |
| 20:11 | masinter | thinks asking Paul Cotton for specific help getting answers to specific technical questions about what IE does would go a long way |
| 20:11 | <gsnedders> | masinter: I was just using it because you had earlier, and because the statements are generally true (and saying IE would limit them to a specific subset of time, not that that is really a problem though). |
| 20:13 | <masinter> | the question on the IRI issue is whether translating an IRI with an illegal character in the domain name should be specified as signalling an error, translating to pct-encoded bytes which would be illegal when later translated to punycode, to some otherwise illegal host name, or whether it was OK to leave it unspecified |
| 20:14 | <masinter> | and the issue is that signalling an error is the safest -- and most appropriate if you're doing resolution -- but that some implementations and processes can't really accept an error signal, so there needs to be alternatives which are also conforming |
| 20:15 | <othermaciej> | Paul Cotton does not know much about IE, and has very clearly stated as much |
| 20:15 | <masinter> | uh, i didn't think he would answer directly |
| 20:15 | <othermaciej> | he does, however, work at the same company as the IE people, so may be better positioned to ask them |
| 20:15 | <othermaciej> | though I would think asking Adrian Bateman might skip a step |
| 20:15 | <masinter> | quite likely |
| 20:16 | <masinter> | i didn't suggest asking paul for answers, if you actually read what I said, Maciej |
| 20:16 | <othermaciej> | Microsoft is often either unwilling or unable to correctly describe how IE works |
| 20:16 | gsnedders | notes we're still waiting for a copy of the stylesheet IE8 uses for quotations marks in various languages in q that has been pending approval for release since last TPAC, and Chris tried to push to get it released several times |
| 20:17 | masinter | bows to authority on the subject of what Microsoft is or isn't unwilling to answer |
| 20:17 | <othermaciej> | s/is often/has often been/ |
| 20:17 | <masinter> | clearly you're all experts on this subject, I confess I've never asked |
| 20:17 | <masinter> | I do know that it's easier to get answers to questions than it is to get anyone to release any software |
| 20:18 | <gsnedders> | masinter: I'd be up for asking them a lot more… if there was much chance at all at getting a response. |
| 20:18 | masinter | repeats, "masinter thinks asking Paul Cotton for specific help getting answers to specific technical questions about what IE does would go a long way" |
| 20:18 | <masinter> | note I didn't say "asking Paul Cotton for answers" |
| 20:18 | <othermaciej> | Microsoft is more engaged in the HTML WG now so it may be more fruitful to ask them questions about their implementation |
| 20:19 | <masinter> | that was my point, thanks |
| 20:19 | <gsnedders> | My point is that past experience makes me still very dubious |
| 20:19 | <masinter> | standards only work when the implementations that need to follow the standard are actually working on the standard |
| 20:20 | <masinter> | otherwise you're playing a game of "we're standard and you're not nyah nyah nyah" |
| 20:21 | <masinter> | which may be fun and satisfying and vindictive, but doesn't actually help make stuff work |
| 20:23 | <masinter> | Hixie: Vint suggested a phone conference on the IRI issue and coordination, could you help set that up? |
| 20:25 | <masinter> | It would be great to get Vint, Klensin, Fielding, Martin, you, me, maybe MNot; not sure who else would be a core group. The goal would be to see if there's a way of fast-tracking agreement. Some folks who might be reluctant to join a meeting might do so if Vint asks them nicely. |
| 20:27 | <masinter> | Maciej, hope that addresses your process questions on IRI progress? |
| 20:28 | <masinter> | maybe getting someone from MS IRI implementation team might be a good addition? not sure |
| 20:28 | <masinter> | Michel was their guy but he's not at MS any more, don't hear from him much |
| 20:28 | tantek | points out Hixie's post on telecons. http://lists.w3.org/Archives/Public/public-html/2009Jun/0616.html |
| 20:29 | <masinter> | that's "weekly telecons" |
| 20:29 | gsnedders | also points out Hixie does not own a phone |
| 20:29 | <masinter> | i'm sure Vint would let him use his phone |
| 20:30 | <masinter> | brb |
| 20:30 | <tantek> | masinter - the *subject* says weekly telecons, but his message addresses "Teleconference calls" and "Teleconferences" in general. |
| 20:35 | <masinter> | this is getting silly. [10:35] <Hixie> masinter`: if there's anything i can do to make hooking html5 into it easier, let me know |
| 20:36 | <masinter> | getting stuff into an IETF document that some IETF participants don't think belongs in the IETF document is the bottleneck |
| 20:36 | <masinter> | and a meeting about requirements and processes was Vint's suggestion for how to unblock the bottleneck, and I agree that normally that would be a good first step |
| 20:37 | <masinter> | and the participants are around the world, the next time for a possible physical meeting would be IETF in Hiroshima in November, the week after the TPAC |
| 20:37 | <masinter> | i've tried to reserve time at the IETF meeting for a "BOF" to discuss it, but making progress on this before November would be much better |
| 20:39 | <masinter> | a phone conference with at least one person with some authority from the concerned parties does seem to me to be a good idea |
| 20:40 | <masinter> | "anything i can do" should cover somehow finding a telphone and participating in a 1-2 hour phone conference |
| 20:43 | <masinter> | at most, maybe less |
| 20:45 | <hober> | what does getting people on the phone get you that publically-archived email doesn't (besides the ability to say things off the record) |
| 20:45 | <hober> | I mean, why not just email the people you're talking about getting on the phone |
| 20:46 | <Philip`> | Lower latency? |
| 20:47 | <masinter> | well, for example, I just made some comments about the phone meeting, about error handling in IRIs, and a couple of other topics, and gotten just silence. On a phone conference, I oculd ask "Well, how about it?" and expect people to answer. Here, who knows? and in email, people can just repeat their stock positions and stonewall an actual discussion |
| 20:49 | <masinter> | that can happen in a phone conference too, of course, but it's more obvious when it's happening |
| 20:49 | <mpilgrim> | yes, standards are much easier when a few good men get together and work out their differences over beers |
| 20:49 | <hober> | beer++ |
| 20:49 | <masinter> | funny |
| 20:49 | <mpilgrim> | how dare we give the uninvited hoi polloi a chance to respond |
| 20:50 | <masinter> | oh exactly, the hoi polloi should definitely have a meeting |
| 20:50 | <jgraham> | masinter: IRC is only occasionally sychronous |
| 20:50 | <mpilgrim> | we're all aware of your opinion about the openness of the htmlwg |
| 20:50 | <masinter> | oh really? gosh |
| 20:50 | <masinter> | are you now? |
| 20:51 | <mpilgrim> | well I am |
| 20:51 | masinter | listens, then |
| 20:51 | <mpilgrim> | as is anyone else who bothers to read ac-forum |
| 20:52 | <jgraham> | secret mailing lists ftw |
| 20:52 | <Steve^> | secret-secret mailing lists even better |
| 20:53 | <masinter> | sigh, definitely private meetings should be outlawed, and private conversations too |
| 20:53 | <Steve^> | masinter, do you want a camera in my bathroom also? |
| 20:54 | masinter | laughs |
| 20:54 | <masinter> | i cant tell if you're trying to be funny, maybe i shouldn't assume you aren't if you don't use :) ? |
| 20:54 | <masinter> | honestly, if you want my opinion about something, you really can just ask me |
| 20:54 | <Steve^> | I wasn't sure if you referred only to whatwg or life in general |
| 20:54 | <mpilgrim> | your love of false dichotomies and other logical fallacies might go a long way towards explaining why you can't seem to find constructive conversation in any medium |
| 20:55 | <masinter> | could you give me an example of a 'false dichotomy'? |
| 20:55 | <masinter> | or a 'logical fallacy'? other than something that you just disagree with? |
| 20:55 | <mpilgrim> | read your own backscroll |
| 20:55 | <masinter> | aww, c'mon, i just asked for an exmaple |
| 20:55 | <mpilgrim> | look in a mirror |
| 20:55 | <masinter> | if you're going to insult me, at least back it up |
| 20:56 | <masinter> | aww, that really hurts, are you going to call me ugly now too? |
| 20:56 | <jgraham> | "private meetings should be outlawed and private conversations too" |
| 20:56 | <masinter> | hey i was joking |
| 20:56 | <mpilgrim> | "sigh, private meeting should be outlawed" |
| 20:56 | <masinter> | yes, that was reducio ad absurdum |
| 20:57 | <masinter> | I suppose I really do need to be more careful among the literal-minded |
| 20:57 | <masinter> | "yes, standards are much easier when a few good men get together and work out their differences over beers" |
| 20:57 | <jgraham> | Hmm, I don't think it has anything to do with being literal minded; it's just not a compelling argument |
| 20:57 | <masinter> | i was going to object that you left out women and vodka |
| 20:58 | <jgraham> | "private mailing lists are bad" "yeah why don't we outlaw private meetings" |
| 20:58 | <masinter> | and cigars, I suppose, but the smoke-filled rooms aren't legal any more in most parts of the world |
| 20:58 | <mpilgrim> | when I came in, you were complaining that no one had responded to your questions for all of 10 minutes |
| 20:58 | julianreschke | can't resist joining a chat that is about Hixie joining a telco |
| 20:59 | <mpilgrim> | and said that wouldn't happen if you held a teleconf |
| 20:59 | <Steve^> | julianreschke, how did you know? |
| 20:59 | <mpilgrim> | and then listed 6 men whom you deemed worthy to join said teleconf |
| 20:59 | <masinter> | I wasn't complaining, i was answering a question about why phone meetings were effective |
| 20:59 | <mpilgrim> | they're not |
| 21:00 | <masinter> | and that wasn't my proposal. my proposal was to have a BOF at the next IETF meeting |
| 21:00 | julianreschke | sometimes looks at chat logs while test cases are running slowly |
| 21:00 | <masinter> | Vint Cerf replied to my call for a BOF, and *he* suggested a phone conference |
| 21:00 | <Steve^> | psst julianreschke, what's a BOF? |
| 21:00 | <mpilgrim> | but you can't see why, because you think you've produced an exhaustive list of everyone with worthwhile oponions, and invited them |
| 21:00 | <mpilgrim> | just like you want to do with the entire htmlwg |
| 21:01 | <julianreschke> | Steve, I think "birds of a feather" meeting |
| 21:01 | <julianreschke> | Steve, something you set up in order to get a WG |
| 21:01 | <masinter> | http://trac.tools.ietf.org/bof/trac/wiki |
| 21:01 | <masinter> | IRIs: Status: received preliminary request from Larry Masinter. Some deep-reaching issues around the IRI architecture would seem to require a WG to be able to decide on possibly major changes. Agenda: in progress, Draft: in progress, Mailing list: uri⊙wo, public-iri⊙wo, Responsible AD: Alexey Melnikov |
| 21:02 | <julianreschke> | http://www.ietf.org/tao.html#anchor34 |
| 21:03 | <masinter> | so i'm in favor of open discussion on an open mailing list in the ietf open process. but Vint suggested a phone call to see if things could be fast-tracked, and Maciej was concerned about schedule and process and how to get this done before last call, and so a phone call among the editors of the documents that need to be coordinated and the chairs of their working groups seemed like it was effective |
| 21:03 | <masinter> | the six people I mentioned were either editors or chairs |
| 21:03 | <masinter> | so it wasn't a random list. i did select, among all the editors and chairs, a smaller set of those who seemed to be active and 'up' on the issues |
| 21:04 | <masinter> | and yes, a meeting of the editors of documents that need to be coordinated about how to go about coordination is more effective than inviting discussion on an open list |
| 21:04 | <masinter> | and mpilgrim's sarcastic comments about this were really juvenile and out of line |
| 21:05 | <julianreschke> | in particular when trying to make progress asynchronously hasn't been quite successful |
| 21:05 | <masinter> | especially when the agenda for the meeting isn't about the substantive content so much as the method for organizing coordination |
| 21:06 | <masinter> | it's useful to be public about the meeting and the participation to make sure that someone who really needs to be there isn't left out, though |
| 21:07 | <masinter> | brb, lunch, snark away |
| 21:07 | <mpilgrim> | your comments on the secret ac-forum mailing list about the htmlwg being a "failed experiment" were juvenile and out of line, but of course they were secret so you get to play good cop in public |
| 21:20 | <othermaciej> | masinter: fwiw, if a phone call helps progress, then I think it is a fine move; and it makes me think that maybe it is remotely possible for a document to be ready in time for HTML WG Last Call |
| 21:21 | <othermaciej> | masinter: however, it does not tell me what should happen if, despite best efforts, such a document is not ready in time, so it doesn't answer my questions |
| 21:21 | <masinter> | i'm not sure what the set of fallbacks should be |
| 21:22 | <masinter> | the last resort is to put stuff back into the HTML document and mark it as "should be replaced but going to last call with this" |
| 21:23 | <masinter> | i don't know how tentative last call documents can be, but i suppose if the working group agrees that it's ok, then that would be a last-resort fallback |
| 21:23 | <othermaciej> | that would be acceptable to me as a last resort; not sure if the rest of the HTML WG would agree, but I hope so |
| 21:23 | <othermaciej> | obviously, having at least an Internet-Draft to reference that contains the needed info would be much preferred |
| 21:23 | <masinter> | well, it would have to be clear that other routes to progress were unavoidably blocked |
| 21:24 | <masinter> | i think it's getting closer, but there are still gaps to a citable document |
| 21:25 | <masinter> | the 'issue' isn't just the technical content, it was also the process and conformance requirements |
| 21:25 | <masinter> | there wouldn't be an 'issue' at all if there weren't other standards that people want to work the same in HTML |
| 21:26 | <masinter> | right? It's not really a technical issue, it's a coordination issue |
| 21:26 | <masinter> | (lunch ready, back in 10) |
| 21:26 | <othermaciej> | ok, see you after lunch perhaps |
| 21:26 | <masinter> | 10 min |
| 21:33 | masinter | returns to the den of trolls |
| 21:34 | <Steve^> | trolls live under bridges |
| 21:35 | <masinter> | maciej, Hixie pointed out that the 'parsing' from the URI spec wasn't actually referenced in my IRI draft; it used to be IRI -> URI and parse URI so it didn't need to be spec'd, but now that it is "parse IRI" first, I need to add some normative text for that |
| 21:35 | <Philip`> | Steve^: Tolkien's trolls don't, and I wouldn't want to accuse him of being wrong |
| 21:36 | <masinter> | there are still some things that were in the HTML document that aren't in the IRI document, but some of those really are specific to HTML; I suppose we could err on the side of including them and moving them back into HTML if necessary |
| 21:36 | <Steve^> | Philip`, good point. If he's correct the trolls are free to come and eat you. |
| 21:36 | <othermaciej> | masinter: regarding the nature of the issue - I believe from the HTML point of view, what is desired is suitable technical content to normatively reference, said content consisting of producer and consumer conformance requirements, and definitions (including definitions of some algorithms) |
| 21:38 | <othermaciej> | masinter: I think the reason there is a coordination issue is because it is controversial in some quarters to define processing for HTML that aligns with legacy UAs and content rather than strictly following the relevant specifications, which are also used in non-HTML contexts |
| 21:39 | <masinter> | uh, i'm having trouble parsing that, lemme see if I can sort it out |
| 21:40 | <othermaciej> | my apologies for the clumsy sentence structure |
| 21:40 | <masinter> | well, just going through it, it's ok |
| 21:41 | <masinter> | I think the document i posted may be buggy, but it has "suitable technical content to normatively reference, said content consisting of producer and consumer conformance requirements, and definitions (including definitions of some algorithms)" |
| 21:42 | <othermaciej> | link? |
| 21:42 | <masinter> | although you might argue that the "definitions of some algorithms" are given by constraints and examples. but at least that's certainly the intent, and my goal was to note any issues and questions and known bugs in the text if they weren't resolved |
| 21:43 | <othermaciej> | (though I would probably leave the detailed technical review to people with more time and expertise than me) |
| 21:46 | <masinter> | sigh, i posted the link here, but the message itself wasn't delivered. it's there now: http://lists.w3.org/Archives/Public/public-iri/2009Sep/0075.html |
| 21:46 | <othermaciej> | I see, thanks |
| 21:47 | <masinter> | hixie already had some comments. i tried to address your comments about the design goals in http://larry.masinter.net/iribis-hack.html#anchor22 |
| 21:48 | <othermaciej> | is there a definition of how to extract the traditional hierarchical URI components from a string that may or may not be a valid IRI? |
| 21:49 | <othermaciej> | your design goals sound good |
| 21:49 | <masinter> | see http://krijnhoetmer.nl/irc-logs/whatwg/20090921#l-257 |
| 21:50 | <masinter> | i thought what was wanted was IRI components, not URI components |
| 21:51 | <masinter> | i think probably what needs to happen is to allow anything in the BNF, and then make illegal characters in components non-conforming afterwards |
| 21:51 | <masinter> | i only started hacking the BNF itself at the last minute, though |
| 21:52 | <masinter> | what the draft now does is suggest that all illegal characters be percent-encoded before parsing |
| 21:53 | <masinter> | which probably has the same result, except for illegal characters in domain names |
| 21:53 | <othermaciej> | BNF is not that useful for defining error-tolerant rules for extracting subcomponents |
| 21:54 | <othermaciej> | it seems to me that there is an ill-defined concept in 3.2, namely the idea of matching a nonterminal production in a grammar in a string that does not satisfy the grammar |
| 21:54 | <masinter> | that's an interesting general statement we could debate, and i'm sure come up with lots of examples where BNF has been useful, even when defining error-tolerant rules |
| 21:54 | <masinter> | there are two issues |
| 21:55 | <masinter> | one is that the syntax doesn't really match ? and there's some failure? Not sure that can happen with the generic parsing, although it can happen with scheme-specific parsing |
| 21:55 | <masinter> | second is that there are otherwise illegal characters |
| 21:56 | <masinter> | the second issue i think is handled by pre-processing: stripping or percent-encoding illegal characters so they odn't appear by the time you get to 3.2 |
| 21:56 | <masinter> | the first, well, it was in the original HTML copy of the its spec for "URL" |
| 21:57 | <masinter> | the plan was to allow HTML5 to normatively reference the "IRI" or "IRI reference" non-terminal as the "conforming producer" requirements, but to mandate "WebAddress processing" for "conforming liberal consumer" |
| 21:57 | <othermaciej> | I think you likely need a state-machine-like formalism to make the definition of component extraction unambiguous for strings that don't match the grammar |
| 21:58 | <othermaciej> | there may be other ways to do it, but I don't recall seeing a successful one in my experience |
| 21:58 | <othermaciej> | Web Address used a state machine formalism: http://www.w3.org/html/wg/href/draft.html#parsing-urls |
| 21:59 | <masinter> | that's certainly another way of approaching the problem, but unlikely to win support from the implementors of other specifications that use IRIs |
| 21:59 | <jgraham> | Why? |
| 21:59 | <masinter> | URIs haven't had a state-machine-like formalism, is there a serious interoperability failure for parsing? |
| 22:00 | <mpilgrim> | yes |
| 22:00 | <othermaciej> | a) implementors of other specifications that use IRIs don't need to use the algorithm for extracting components from a possibly-invalid string |
| 22:00 | <masinter> | example? |
| 22:00 | <mpilgrim> | but nobody in your group cares, because it's only browsers |
| 22:00 | <othermaciej> | b) what jgraham said |
| 22:00 | <masinter> | they don't? |
| 22:00 | <mpilgrim> | well, roy doesn't |
| 22:01 | masinter | sighs |
| 22:01 | <jre> | othermaciej, RFC3986 already has an example for that: http://greenbytes.de/tech/webdav/rfc3986.html#regexp |
| 22:01 | <jre> | I think that works with IRIs as well |
| 22:01 | <hsivonen> | masinter: the Jena IRI lib implements, IIRC, about six distinct URL-like things but none of them provide my app the behavior I need to make img src resolve the way it does in browsers |
| 22:02 | hsivonen | should really be asleep already |
| 22:02 | masinter | wonders why a state-machine algorithm is better than a regular expression |
| 22:03 | <masinter> | they're both implementations. i'd think the regexp would be just as precise and much less wordy |
| 22:03 | <masinter> | no offense to Jena, but was this a spec problem, or were they just trying to be compatible with six different implementations? |
| 22:04 | mpilgrim | sighs |
| 22:04 | <masinter> | i mean, the problem with reverse-engineering URIs is that there are lots of different implementations, it's not the same game as trying to get out in front of IE |
| 22:04 | <gsnedders> | masinter: URI, IRI, XML's URI thingy in SYSTEM, I can't remember the others |
| 22:05 | <mpilgrim> | we need a spec that says how img src resolves in browsers |
| 22:05 | <mpilgrim> | you can call it whatever you like |
| 22:05 | <masinter> | mpilgrim: not sure which of your comments i should respond to first |
| 22:05 | <mpilgrim> | call it the "img src attribute spec" |
| 22:05 | <mpilgrim> | whatever |
| 22:06 | <mpilgrim> | i don't care |
| 22:06 | <masinter> | http://larry.masinter.net/iribis-hack.html#anchor22 lists what i thought the goals were |
| 22:06 | <masinter> | for the document in which they appear |
| 22:07 | <masinter> | and "Consistency of web and other Internet applications" argues against just defining the "img src attribute spec" |
| 22:07 | <mpilgrim> | i don't know how much clearer i can be |
| 22:07 | <mpilgrim> | that's a fun-looking set of design goals |
| 22:07 | <masinter> | if it's different for HTML and me sending you a URI via IRC |
| 22:07 | <mpilgrim> | go have fun with that |
| 22:07 | <mpilgrim> | we'll find someone else to spec the img src attribute |
| 22:08 | <Philip`> | Seems like the consistency goal is already lost, if Jena has to have six URL-like things |
| 22:08 | <mpilgrim> | actually, we'll just use what we already wrote |
| 22:08 | <jgraham> | (epecially if hsivonen has to implement a seventh to get the behaviour he needs) |
| 22:08 | <mpilgrim> | and then handed off to you, before you broke it |
| 22:09 | <masinter> | mpilgrim: i was trying to actually address the issue that was raised |
| 22:09 | <masinter> | and you might not agree that the issue needs to be addressed at all |
| 22:09 | <gsnedders> | masinter: IRI, RDF URI reference, XML Schema anyURI, XML System ID, xlink:href are the six Jena IRI lib supports |
| 22:09 | <gsnedders> | + URI |
| 22:10 | <masinter> | yes, that's the result of people going off and writing their own spec in a snit, rather than actually trying to coordinate |
| 22:10 | <mpilgrim> | ^-- do any of these define any kind of error handling? |
| 22:10 | <masinter> | so there can be a 7th one, called "HTML5 URL" and an 8th and 9th too |
| 22:11 | <mpilgrim> | there *is* a 7th one |
| 22:11 | <mpilgrim> | you can call it whatever you like |
| 22:11 | <mpilgrim> | and you can spec it, or not |
| 22:11 | <mpilgrim> | but you can not -- i repeat, can not -- will it out of existence |
| 22:11 | <masinter> | hmmmm |
| 22:11 | <mpilgrim> | it will continue to exist, whether you document it or not |
| 22:11 | <mpilgrim> | me, i prefer things like that to be documented |
| 22:12 | masinter | wonders if i am going to be forbidden to put cheese on toast next |
| 22:12 | <jgraham> | ? |
| 22:13 | <masinter> | i'm not sure what i'm trying to will out of existence |
| 22:13 | <mpilgrim> | the algorithm used to resolve an img src attribute |
| 22:13 | <othermaciej> | jre: interesting |
| 22:13 | <jre> | mpilgrim, I don't think anybody proposed not to document it; what's controversial is how exactly to do that |
| 22:13 | <othermaciej> | jre: it's very hard for me to tell what that regexp is doing or if it is correct |
| 22:14 | <mpilgrim> | jre, trust me, there are people who do not want to document it |
| 22:14 | <mpilgrim> | because it involves *gasp* error handling |
| 22:14 | <mpilgrim> | and defining error handling is simply not done |
| 22:14 | <mpilgrim> | in polite society |
| 22:14 | <mpilgrim> | or something |
| 22:14 | jgraham | agrees with othermaciej |
| 22:15 | <jgraham> | And presumbly it would be even worse with error handling |
| 22:15 | <othermaciej> | masinter: I believe finite state machines and regular expressions are equivalent in what languages they can recognize |
| 22:15 | <jre> | mpilgrim, I have no problem in defining the error handling UAs do |
| 22:15 | <mpilgrim> | me neither |
| 22:15 | <othermaciej> | masinter: so a regexp is just a compact (and possibly hard to understand, or maybe easy to understand) way of defining a state machine |
| 22:15 | <mpilgrim> | i'm just telling you that there are people who do, most definitely, have a problem defining the error handling UAs do |
| 22:15 | <jre> | but I do have a problem requiring *everybody* to do that |
| 22:15 | <masinter> | well, there is at least 30 years of experience in writing parsers that implement languages based on grammers given for the language |
| 22:16 | mpilgrim | waits for masinter to mention interlisp |
| 22:16 | <jre> | Maciej, the regexp was written by Roy, so it must be correct |
| 22:16 | jre | ducks |
| 22:16 | <jgraham> | From the point of view of a QA it is difficult to tell from that regexp what the unusual cases i.e. the most likely interoperability problems are |
| 22:16 | <masinter> | yuk yuk, we're getting funny again |
| 22:17 | <jgraham> | (actually it's pretty difficult to tell *anything* from that regexp...) |
| 22:17 | <mpilgrim> | s/have a problem defining/have a problem WITH defining/ |
| 22:17 | <masinter> | i don't think the regexp is normative, so maybe that's moot |
| 22:18 | mpilgrim | wonders, again, if any of the 6 specs gsnedders listed define error handling |
| 22:18 | <othermaciej> | jgraham: you could rewrite the regexp formally as a finite state machine |
| 22:18 | <masinter> | mpilgrim, those weren't 'specs' they were implementations |
| 22:18 | <jgraham> | othermaciej: Indeed. I'd rather not have to if that's alright with you :) |
| 22:18 | <masinter> | specs constrain implementations that are intended to be compliant with them |
| 22:18 | <mpilgrim> | IRI is not a spec? |
| 22:18 | <othermaciej> | jgraham: that is probably what I would do if I was really determined to find out if it processes things in a suitable way |
| 22:19 | <gsnedders> | masinter: RDF isn't a spec? |
| 22:19 | <mpilgrim> | and right away, we're done here |
| 22:19 | <mpilgrim> | your view of a "spec" is narrow and naive |
| 22:19 | <masinter> | he was tlaking about 6 implementations that are intended to be compliant with 6 specs |
| 22:19 | <masinter> | mpilgrim, how many specs have you written or edited? |
| 22:20 | <mpilgrim> | and i clearly meant "do any of the 6 specs which jeni implements" define error handling |
| 22:20 | <mpilgrim> | again with the appeals to authority |
| 22:20 | <mpilgrim> | don't forget interlisp! |
| 22:20 | <othermaciej> | jgraham: actually, I can sort of tell what it's doing when I stare real close |
| 22:20 | masinter | sighs |
| 22:20 | <Philip`> | Is there some common formalism for finite state machines with capturing groups? |
| 22:21 | <othermaciej> | jgraham: essentially each component has a potential set of stop characters, and keeps going until you see one of those |
| 22:21 | <masinter> | i think "define error handling" isn't very clear |
| 22:21 | <Philip`> | (The regexp matches any string at all, so the capturing is the only interesting part of it) |
| 22:21 | <masinter> | it's a shorthand for something that really has a lot of possible ways of accomplishing it |
| 22:21 | <jgraham> | othermaciej: Yeah. But it is hardly obvious |
| 22:21 | <othermaciej> | Philip`: other than a regexp, I think the common ways to describe FSMs are prose or state transition diagrams |
| 22:21 | <othermaciej> | state transition diagrams could have capture of part of the input as a transition action |
| 22:22 | <jre> | mjs, exactly; and surprise, that's how people implement it in practice |
| 22:22 | <mpilgrim> | oh for christ's sake |
| 22:22 | <mpilgrim> | even the xml spec defines error handling |
| 22:22 | <mpilgrim> | (it's simplistic, naive, harmful-to-the-web draconian error handling, but it tells you what to do with something that purports to be xml but isn't) |
| 22:22 | jre | sees an appeal to authority |
| 22:23 | jgraham | sees the appeal of bedtime |
| 22:24 | <othermaciej> | masinter: in the context of URI/IRI/URL/*R*, "define error handling" means that the various operations you can perform on a resource identifier have well-defined behavior when applied to a string that is not a conforming resource identifier of the appropriate kind |
| 22:24 | Philip` | sees a peal of bells |
| 22:24 | <othermaciej> | operations such as "dereference", "extract the host component", "compare for equality to another *R*" , etc |
| 22:25 | <othermaciej> | and in the context of *R* in Web browsers, the defined behavior of those operations has some legacy constraints and cannot simply be "signal an error" |
| 22:26 | <masinter> | well, let me go through those |
| 22:26 | <masinter> | "dereference" is a complex process, that involves parsing and then translating into some protocol action |
| 22:27 | <masinter> | and the activities of dereferencing URIs (and IRIs) is delegated to the spec for the scheme |
| 22:27 | <masinter> | so how to dereference a http URI is different than how to dereference a 'data:' or 'about' URI |
| 22:27 | <masinter> | there's a gap between the HTML and URI/IRI and HTTP specs about where the spec now in HTML belongs, I admit |
| 22:28 | <masinter> | which I think i could argue that it belongs in the HTTP spec, except for the parsing part, since the HTTP spec includes the http URI scheme |
| 22:29 | <masinter> | "extract the host component", I think that's in the IRI draft, and that it should cover non-conforming input at least to some degree |
| 22:30 | <masinter> | although we had that long conversation about whether it was really a good idea, for example, to not allow implementations to choose whether "signal an error or exception" or "pass through some error signal as error output" |
| 22:30 | <masinter> | because which is preferable and correct might depend on legtimate differences in implementation mode |
| 22:31 | <masinter> | compare for equality: the draft has long contained a ladder of comparison methods |
| 22:31 | <masinter> | and if the four (five? don't remember) different comparison methods listed aren't specified sufficiently, that would be a bug |
| 22:33 | <masinter> | re: "the defined behavior of those operations has some legacy constraints and cannot simply be "signal an error", the goal was to provide some way of calling for a parsing method which wouldn't have any such error states, by removing otherwise illegal characters |
| 22:36 | <othermaciej> | I guess Hixie also named the need for an absoluteness test that can be applied to a possibly nonconforming possibly relative IRI reference |
| 22:37 | <masinter> | yes, the 'absolute' test should be whether or not there's a scheme, independent of whether the rest of it is legal |
| 22:37 | <othermaciej> | and also a way to resolve an IRI reference relative to a base where one or both may be nonconforming |
| 22:37 | <masinter> | that used to be inherited from URI because IRI -> URI translation was done first |
| 22:38 | <masinter> | there are a couple of things i'm not sure of |
| 22:38 | <masinter> | for example, how could you ever get a 'base' with a fragment identifier? |
| 22:38 | <othermaciej> | <base> tag in HTML for instance |
| 22:39 | <othermaciej> | <base href=""> can make an arbitrary string your base |
| 22:39 | <masinter> | sorry, hmmm, someone was asking me whether fragment should be stripped |
| 22:39 | <masinter> | yes, i mean, but why would anyone do that, that's what i meant |
| 22:40 | <masinter> | at one point i was convinced that we needed to update the URI spec so that the relative + base algorithm could be updated |
| 22:40 | <masinter> | and that might be still be the conclusion |
| 22:41 | <othermaciej> | I don't think there is a good reason to do it, but I suspect there are people doing it inadvertently and relying on certain behavior |
| 22:41 | <masinter> | the IRI document already swiped the BNF from URI and just tweaked it in place, probably the right thing to do is the same for the relative + base calculation |
| 22:42 | <othermaciej> | it would probably be best to define both in one spec, and make "conforming URI" a strict subset of "conforming IRI" |
| 22:42 | <othermaciej> | typing and reading the term "IRI" hurts me |
| 22:42 | <masinter> | yeah, it's just harder to get there process-wise |
| 22:43 | <masinter> | well, that's what i wanted to do, but i was convinced "one step at a time" |
| 22:43 | <jre> | "conforming URI" *is* a subset of "conforming IRI" |
| 22:43 | <masinter> | i mean, Roy was at least willing to admit that updating the URI spec might happen *sometime* |
| 22:44 | <othermaciej> | coffee break, adieu for now |
| 22:44 | <masinter> | probably in the same time frame as HTML5 reaching Rec |
| 22:45 | <masinter> | mpilgrim, you said a lot of things in passing that i didn't respond to, wonder if you want to go back and talk about any of them? "failed experiment", "secret AC mailing list postings", "interlisp", "false dichotomy" or "logical fallacy" |
| 22:46 | <masinter> | or are you just the troll from Google? |
| 22:47 | <mpilgrim> | "interlisp" is a reference to this epic thread on public-html a few months ago: http://lists.w3.org/Archives/Public/public-html/2009May/0571.html |
| 22:47 | <mpilgrim> | "failed experiment" is what you have repeatedly called the HTML WG |
| 22:47 | <masinter> | let's take 'em one at a time, ok? |
| 22:47 | <mpilgrim> | a "logical fallacy" is an error in reasoning |
| 22:48 | <mpilgrim> | a "false dichotomy" is a kind of logical fallacy |
| 22:48 | <mpilgrim> | where you act as if there are only two options (usually polar opposites), when in fact there are more options |
| 22:48 | <masinter> | so, Interlisp is some work I did mainly in the 70s |
| 22:48 | <masinter> | can we do this one at a time, or do you want to overwhelm me with your fancy footwork? |
| 22:48 | <masinter> | and I didn't bring it up |
| 22:48 | <masinter> | God knows, Roy did |
| 22:49 | <masinter> | and frankly, i wouldn't bring up Interlisp in a standards discussion; i'm not ashamed of it, but it was a long time ago, got some recognition so that's ok |
| 22:49 | <mpilgrim> | ac-forum is, in fact, a secret mailing list |
| 22:49 | <mpilgrim> | not that its existence is a secret |
| 22:49 | <masinter> | i did work on the common lisp standard |
| 22:49 | <mpilgrim> | but that its contents are only available to w3c members |
| 22:49 | <mpilgrim> | and not to the general public |
| 22:50 | <masinter> | sigh ok, i'm going to respond one at a time? |
| 22:50 | <masinter> | or do you want to talk about all of these at once? what's your preference? |
| 22:50 | <mpilgrim> | let's start with the "failed experiment" bit |
| 22:50 | <masinter> | and still, i don't think i need to rest on 'authority' here, and I don't htink i need to |
| 22:50 | <masinter> | ok |
| 22:50 | <masinter> | so, i really put a lot of effort into the W3C process document |
| 22:51 | <masinter> | and i've really thought a lot about standards processes, i've worked in ANSI and ISO and IETF and W3C and watched other groups as well |
| 22:51 | <masinter> | and the HTML-WG is different from most other W3C groups |
| 22:51 | <masinter> | and it was explained as an "experiment" |
| 22:51 | <masinter> | right? |
| 22:52 | <masinter> | that was the idea, W3C and WhatWG working together in this process is an experiment for W3C? |
| 22:52 | <masinter> | the posting was in the middle of a conversation of W3C members about how the W3C management should spend the W3C member's money |
| 22:52 | <masinter> | at the time, I was Adobe's AC representative, I'm not now |
| 22:53 | <masinter> | well, when you do an experiment, you try to figure out whether things are working |
| 22:53 | <mpilgrim> | i am aware of the context |
| 22:54 | <mpilgrim> | i read the entire archives, not just selected ones |
| 22:54 | <masinter> | so i don't really want to debate whether the 'experiment' has 'failed' now, things seem to be working better |
| 22:54 | <mpilgrim> | i've also read the w3c's financial group's report |
| 22:54 | <masinter> | in general, standards really only work when the implementors of the specification participate in the process |
| 22:54 | <masinter> | and more of that seems to be happening, so that's good |
| 22:55 | <masinter> | the IETF has different process -- all mailing lists are open, there are no dues, i've done more work in IETF than in W3C |
| 22:56 | <masinter> | i've been chair of two IETF working groups (URI and HTTP), editor of lots of IETF documents, and member of dozens of other working groups; so I think I can have an opinion -- which is really all i was saying -- about how well the experiment was going |
| 22:57 | <masinter> | the merger of the open mailing list anyone can chat with the formal W3C meeting/voting/representative methods still is really in conflict, and i'm still not sure how it will work out |
| 22:57 | <masinter> | as for whether the mailing list is open or secret -- well, you read it and you're talking about it, so either it's not really secret, or you're violating the membership agreement, since this conversation is public |
| 22:58 | <masinter> | i don't care if you want to repost my old message, but i think it's old news |
| 22:58 | <masinter> | i'd rather just see if we can fix the spec and get on with it. |
| 22:58 | <masinter> | OK? |
| 22:59 | <mpilgrim> | i prefer to judge working groups by their results |
| 22:59 | <masinter> | that's always the best, but i'm not sure everyone agrees on 'results' |
| 22:59 | <mpilgrim> | rather than their adherence to some process document |
| 22:59 | <masinter> | i think it would be bad if IRIs in HTML and IRIs in instant messaging worked differently |
| 23:00 | <mpilgrim> | i'm sure the document is quite well-written and all that |
| 23:00 | <mpilgrim> | in fact, i've read it, and i can confirm that it is well-written |
| 23:00 | <masinter> | i think it's bad that there are 6 |
| 23:00 | <mpilgrim> | but w3c process is what caused the WHATWG in the first place |
| 23:01 | <masinter> | i don't think 'well-written' is well-defined actually |
| 23:01 | <masinter> | there are various things you want a spec to do, and the question is whether the spec actually does that |
| 23:01 | <masinter> | you write a specification that implementors agree to implement |
| 23:01 | <masinter> | and how "well written" it is may depend on how broad that agreement is |
| 23:03 | <masinter> | anyway, have we handled your "failed experiment" and "secret AC mailing list" posting issues? |
| 23:03 | <masinter> | i'm not sure if you wanted me to blog about it more publicly, or use nicer words, or what? Were you offended by what I said? |
| 23:05 | sicking | is just happy to have an IETF spec that matches reality |
| 23:06 | <masinter> | well, I'm not sure 'matches reality' is always the most important goal |
| 23:06 | <mpilgrim> | the fact that you bring up w3c membership agreements just highlights how broken the w3c really is |
| 23:06 | <sicking> | masinter: well, at *some* point reality and the spec is going to match i hope? |
| 23:07 | <sicking> | be that reality changing, or spec changing, or both |
| 23:07 | <masinter> | yes, a good specification leads the community to uniformly implement something that improves their mutual benefit |
| 23:07 | <mpilgrim> | but sure, i guess i'd done talking about it |
| 23:07 | <masinter> | it's a "tragedy of the commons" situation |
| 23:07 | <mpilgrim> | did you want to talk about the other points? |
| 23:08 | <masinter> | anything you want, I can't do this the rest of this week |
| 23:08 | <masinter> | I'm secretly meeting with 8 other men over beer to work out the future of the web, without the hoi polloi having a say |
| 23:09 | <mpilgrim> | well, i retract the part about the beer |
| 23:09 | <mpilgrim> | apparently there is no beer |
| 23:09 | <masinter> | http://www.w3.org/2001/tag/2009/09/23-agenda |
| 23:09 | <masinter> | last F2F we definitely had beer |
| 23:09 | <masinter> | not during the meetings tho |
| 23:10 | <masinter> | i dunno, "false dichotomy" and "logical fallacy" |
| 23:11 | <masinter> | sound like ways of saying that you disagree with me |
| 23:12 | <masinter> | i'm willing to have a discussion and listen to arguments, hope you are too |
| 23:12 | <mpilgrim> | "[16:01] <masinter> sigh, definitely private meetings should be outlawed, and private conversations too" |
| 23:12 | <masinter> | well, i explained again, i was being ironic |
| 23:12 | <mpilgrim> | yes |
| 23:12 | <mpilgrim> | my irc client must have dropped your smiley |
| 23:12 | <masinter> | i think sam covered this already, someone complained that Ian had a private meeting and Sam defended it saying private meetings were ok |
| 23:13 | <mpilgrim> | private meetings are great |
| 23:13 | <mpilgrim> | making decisions in private meetings is not |
| 23:13 | <masinter> | i know of no standards group that has a process for making decisions in private meetings |
| 23:13 | <mpilgrim> | (unless the entire process is private, of course) |
| 23:13 | <masinter> | well, wait |
| 23:13 | <masinter> | i take it bak |
| 23:14 | <masinter> | sure, there are private meetings |
| 23:14 | <masinter> | the W3C process was modeled after the X consortium |
| 23:14 | <masinter> | at least as the starting point. Not sure that was the best model |
| 23:15 | <masinter> | in my view, W3C was started in the first place because the IETF process wasn't converging |
| 23:15 | jre | wonders how to get Mark P. to fix http://code.google.com/p/doctype/wiki/APingAttribute, as editing the Wiki does not work (and hasn't worked since last year) |
| 23:15 | <masinter> | I was in the HTML working group in IETF, with open meetings and postings and mailing lists, and there was an irreconcilable gulf between "inline <font>" and style sheets |
| 23:17 | <masinter> | and people thought "this kind of open consensus process doesn't work for HTML, we need a working group with representatives who can *vote* and use *majority voting* to resolve these kinds of things |
| 23:17 | <masinter> | so this seems to me to be repeating history -- the more things change, the more they stay the same |
| 23:18 | <mpilgrim> | jre: we're migrating the site to a different backend CMS |
| 23:19 | <mpilgrim> | masinter: yeah, and the first thing the w3c did when they took html under their wing was to create html 3.0 |
| 23:19 | <masinter> | well, you know, you talk about 'the w3c' as if Opera, Apple, Google, and Mozilla aren't members |
| 23:19 | <mpilgrim> | backtracked in 3.2, produced something halfway usable in 4.0, then abandoned it altogether |
| 23:19 | <mpilgrim> | not the greatest track record |
| 23:20 | <jre> | mpilgrim, good to known; it would be even nicer if people's bug reports would be replied to; at least now I know what may be going on |
| 23:20 | <masinter> | the problem with HTML in W3C is that neither Netscape nor Microsoft wanted to play |
| 23:22 | <masinter> | I can't say W3C HTML working group was the most effective working group I'd seen (I was on the committee as the rep from Xerox in the late 90s) but if the browser vendors didn't want to play, there was no way of making them |
| 23:25 | <masinter> | standards groups like IETF and W3C are more like convention centers: they provide the meeting rooms and projectors and some process management, but no work gets actually done except by the people who come. Talking about it as "the W3C" vs. "Opera & Mozilla & Apple & Microsoft & Google" seems to leave out the fact that (well, maybe not Google at the time?) they were that those who needed to play weren't willing to play at the W3C |
| 23:25 | <masinter> | so it's not clear who you are blaming for the failure, mpilgrim? |
| 23:25 | <masinter> | some staff members? |
| 23:26 | <masinter> | why didn't Apple or Opera or Microsoft send people to the W3C HTML working group meetings to actually create a useful standard way back then? |
| 23:28 | <masinter> | s/useful/better/ |
| 23:30 | mpilgrim | wonders if masinter was present at the 2004 workshop on web applications |
| 23:30 | <mpilgrim> | or knows the history of said workshop |
| 23:31 | <masinter> | i wasn't there |
| 23:31 | <masinter> | i know the history |
| 23:31 | <hober> | http://www.w3.org/2004/04/webapps-cdf-ws/ and http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html for those reading the archives who don't know the history |
| 23:31 | <othermaciej> | the W3C voted to reject further work on HTML in favor of XHTML2, SVG and compound documents |
| 23:31 | <masinter> | my impression is that WhatWG was already started months before, the legal agreement for copyright between Opera and Mozilla already in place. The WhatWG was *announced* a few days after, but the spec had been in preparation for months before in private email |
| 23:32 | <Hixie> | the legal agreement for copyright between Opera and Mozilla and Apple happened about 6 months after the workshop |
| 23:32 | <mpilgrim> | actually i think the archives are down at the moment, but thanks hober for the links |
| 23:32 | <Hixie> | and the spec had been public the whole time since the xforms PR vote |
| 23:33 | <othermaciej> | my recollection is that originally the only spec being worked on was Web Forms 2 as a reaction to XForms |
| 23:33 | <masinter> | ah ok |
| 23:33 | <masinter> | so there were no plans to fork a separate group before that workshop? |
| 23:33 | <Hixie> | there were backup plans |
| 23:33 | <Hixie> | but the whatwg site was only announced because the w3c said that the browser vendors weren't welcome |
| 23:33 | <Hixie> | we were hoping to not use it |
| 23:33 | <Hixie> | and we didn't threaten with it or anything |
| 23:34 | <masinter> | no i'm sure |
| 23:34 | <othermaciej> | I can't speak for anyone else, but Hyatt and I were the ones involved in this from Apple's end and we had no prior intent to make a breakaway group or interest in doing so |
| 23:34 | <masinter> | i'm just saying talking about "the W3C" as if it were someone else doesn't make a lot of sense if you're a member company |
| 23:34 | <masinter> | or from a member company |
| 23:34 | <Hixie> | it makes a lot of sense when the W3C staff are the ones who tell you (a member company) to go elsewhere |
| 23:34 | <Hixie> | which actually happened at that meeting |
| 23:34 | <masinter> | well, the staff isn't in charge, the members are |
| 23:35 | <othermaciej> | it makes sense in the same way as it makes sense to complain about US policy even when one is an American voter |
| 23:35 | <mpilgrim> | and i'm just saying that there were w3c member companies at a w3c workshop who were told in no uncertain terms that html was dead and that they were not permitted to work on it further within the w3c |
| 23:35 | <masinter> | well, how many members are there who vote? |
| 23:35 | <othermaciej> | members get to vote on very few things |
| 23:35 | <Hixie> | anyway that's all in the past, the future is what matters. the w3c said that they were sorry and we were right and xhtml2 was wrong and so we can move on to more important things now |
| 23:35 | <othermaciej> | mostly their input is advisory and the decision is made by w3c staff |
| 23:35 | <masinter> | yes, exactly |
| 23:35 | <masinter> | i didn't bring up this past stuff |
| 23:36 | mpilgrim | wonders why masinter, author of the w3c process document, doesn't know the answers to these questions |
| 23:36 | <masinter> | sorry, which questions? |
| 23:36 | Hixie | goes back to actually improving html |
| 23:36 | <othermaciej> | I think it's relevant to why W3C Member organizations may have valid reason to complain about the actions of "the W3C" |
| 23:36 | <othermaciej> | but yes, it's also water under the bridge |
| 23:37 | <othermaciej> | I think HTML is on a good course now, and despite the flamewars and process wrangling I am happy with where things are going |
| 23:38 | <masinter> | i think there's a lot of work to be done, and my estimate of what needs to be done is probably a lot more than you think needs to be done, but fixing things does seem like the right direction |
| 23:38 | mpilgrim | thinks HTML was on a good course before the W3C came back into the picture |
| 23:38 | <masinter> | do i get to ignore mpilgrim's flaming or what? |
| 23:38 | <hober> | masinter: it's IRC. you get to /ignore whomever you please. |
| 23:38 | <othermaciej> | this channel has been more entertaining today than it has been in months |
| 23:39 | <Lachy> | from what I can tell from my archives, the spec's current copyright licence was sorted out around November 2004, and it took the 6 months since June 2004 for the lawyers to finally sort it out. |
| 23:39 | <masinter> | people were saying there was some "cultural difference" so i thought "nah, i can speak that language" |
| 23:39 | <Hixie> | Lachy: that's what i said :-) |
| 23:40 | <mpilgrim> | i realize there was a desire to get MS to agree to a patent policy, but i think that has come at too high a price |
| 23:40 | <Lachy> | ok. I only skimmed the logs. Didn't see you mention the dates |
| 23:40 | <othermaciej> | the conversation here is at times messy and rambunctious and not always 100% serious |
| 23:40 | <Hixie> | (Lachy: i only said 6 months) |
| 23:40 | <Hixie> | "not always" is putting it mildly |
| 23:41 | <masinter> | well, i think the arguments about process really are dead, but wish mpilgrim would stop bringing them up |
| 23:41 | masinter | wants the topic to be renamed to 'den of trolls' |
| 23:41 | <mpilgrim> | that topic has certainly been apropos today, but not for the reason you think |
| 23:41 | <othermaciej> | I think the reason people reading the logs sometimes get very upset is lack of context and missing the tone, rather than a cultural barrier |
| 23:42 | <Hixie> | mpilgrim: i think we should have tried harder to get a patent policy outside the w3c, but i think microsoft's involvement is important |
| 23:42 | <masinter> | the patent policy is held up way too much, and isn't really very effective here anyway |
| 23:42 | <masinter> | but IANAL so i'll shut up |
| 23:42 | <mpilgrim> | microsoft's involvement was relatively... minimal... before august 7 |
| 23:42 | <mpilgrim> | so i'm not sure that argument holds up either |
| 23:43 | <othermaciej> | having a patent policy and having microsoft's participation are both valuable |
| 23:43 | <mpilgrim> | agreed |
| 23:43 | <mpilgrim> | but at what price? |
| 23:43 | <Hixie> | mpilgrim: oh i think we failed to get any significant useful input from them, but that doesn't mean it wasn't worth trying to get it |
| 23:43 | <Hixie> | mpilgrim: it was the Right Thing To Do |
| 23:43 | <Hixie> | mpilgrim: even if it had a high cost |
| 23:43 | <Hixie> | mpilgrim: however, we should have done it outside the w3c |
| 23:43 | <Philip`> | Does implementing and shipping HTML5 features in IE8 not count as involvement? |
| 23:43 | masinter | isn't going to talk about process any more |
| 23:44 | <mpilgrim> | hixie: i disagree, but i've never been known as a bridge-builder |
| 23:44 | <mpilgrim> | ;) |
| 23:44 | <masinter> | on the text/html mime type registration? i'm not happy obsoleting http://www.ietf.org/rfc/rfc2854.txt with the text you have |
| 23:45 | <mpilgrim> | bbiab, dinner |
| 23:45 | <masinter> | i could see adding stuff, sure, but don't know why anything in that document is wrong |
| 23:45 | <Hixie> | masinter: please send e-mail or file a bug; i don't track feedback from irc (due to the difficulty in doing so) |
| 23:45 | <masinter> | i thought there might be a difference of opinion about what a MIME type registration is for? |
| 23:47 | <masinter> | the issue was open and got closed in HTML-WG and i didn't want to try to repoen it in HTML-WG without a discussion |
| 23:47 | <Hixie> | masinter: possibly, but right now my brain is looking at how to determine what exceptions should be raised when a negative integer is given as the new value of an unsigned long IDL attribute, and I don't really have the bandwidth to do both |
| 23:48 | <masinter> | ok |
| 23:48 | <Hixie> | speaking of which, what exceptions should be raised when a negative integer is given as the new value of an unsigned long IDL attribute? |
| 23:48 | <Hixie> | WebIDL doesn't seem to define it |
| 23:48 | <Hixie> | heycam: yt? |
| 23:48 | <heycam> | hi Hixie |
| 23:48 | <Hixie> | so i have a stupid case to deal with |
| 23:48 | <Hixie> | maxLength on <textarea> and <input> |
| 23:49 | <Hixie> | has to return -1 when the content attribute is missing |
| 23:49 | <Hixie> | but has to only accept non-negative new values on setting |
| 23:49 | <Hixie> | what exception shoul i throw? |
| 23:49 | <heycam> | ok |
| 23:49 | <heycam> | does it have to accept values >2**31 |
| 23:49 | <heycam> | ? |
| 23:49 | <Hixie> | no |
| 23:49 | <heycam> | so you'll be giving an unsigned long type? |
| 23:49 | <heycam> | s/an/it an/ |
| 23:50 | <Hixie> | the IDL attribute will be just long, i think |
| 23:50 | <heycam> | oops |
| 23:50 | <Philip`> | What if I want to copy-and-paste a DVD into a text input box? :-( |
| 23:50 | <heycam> | sorry |
| 23:50 | <Hixie> | since it needs to return -1 |
| 23:50 | <heycam> | i thought signed but typed unsigned :) |
| 23:50 | <Hixie> | Philip`: don't set maxlength then :-P |
| 23:50 | <Hixie> | heycam: heh |
| 23:50 | <masinter> | bye, i'll probably not be back until next Sunday so save up your darts |
| 23:50 | <Philip`> | Hixie: Oh, that sounds good enough |
| 23:50 | <Hixie> | heycam: basically it's a long, but i want it to pretend to be unsigned long when the new value is negative |
| 23:50 | <heycam> | silly question then, what exceptions do impls throw currently? |
| 23:51 | <heycam> | but if you don't need values >2**31 it seems like it really is signed |
| 23:51 | <Hixie> | interoperability is not a strong point of this area of the platform |
| 23:51 | <heycam> | just you can't assign all values to it |
| 23:51 | <heycam> | which isn't an uncommon thing |
| 23:51 | <Hixie> | i seem to use INDEX_SIZE_ERR in similar cases |
| 23:51 | <heycam> | well i would suggest a DOMException of some kinda, rather than an ES exception |
| 23:51 | <Hixie> | k |
| 23:52 | <Hixie> | i'll use INDEX_SIZE_ERR |
| 23:52 | <Hixie> | thanks |
| 23:52 | <heycam> | yeah, though poorly named, it's probably the closest |
| 23:52 | <othermaciej> | Hixie: DOM APIs have historically given INDEX_SIZE_ERR in such cases |
| 23:53 | <othermaciej> | (the language around this is a little wacky, since in the DOM's model of IDL, there should be no such thing as assigning a negative number to an unsigned attribute) |
| 23:54 | <othermaciej> | I don't remember what happens for out-of-range magnitude or non-integer values (that would be in range if truncated) |
| 23:54 | <Hixie> | yeah there isn't in webidl+html5 now either, the exception for that case will be in webidl |
| 23:54 | <Hixie> | but sadly this is one of those special cases |
| 23:54 | <Hixie> | ...like almost everything else in html5 |
| 23:54 | <heycam> | Hixie, i don't think it's such a special case really. i don't see it as problematic or inconsistent at all. |
| 23:55 | <heycam> | if it did accept assigning values >2**31 then it would be |
| 23:55 | <othermaciej> | so if you find something in HTML5 that's *not* a special case... then wouldn't that be a particularly special case? |