| 00:29 | <TabAtkins> | Who all is in the cabal? Me and Aryeh are American. |
| 03:16 | <bartek> | Hi. I'm testing out some HTML5 code, mainly using some SVG. I've set my <!DOCTYPE html> but it seems if I serve the file locally, using a simple http server from python I get nothing. If I view the same code online, it works. Do I need be to sending specific mimetypes to the browser in order for it to render the html correctly? |
| 03:17 | <inimino> | bartek: should be text/html, most any HTTP server will do that automatically if the filename ends with ".html" |
| 03:18 | <Dashiva> | Many browsers let you see the mimetype from the server |
| 03:18 | <bartek> | hmm, then I wonder what the issue is |
| 03:18 | <bartek> | I literally get no rendering of html5-spec stuff on my localhost |
| 03:38 | <bartek> | Ah, I figured it out. I need to be serving back text/xml, not text/html. The browser renders it great if it's text/xml but I might be wrong and just setting something weird in my code .. :) |
| 03:38 | <bartek> | (it works now, though) |
| 03:51 | <TabAtkins> | bartek: Sounds like your browser isn't using an html5 renderer. If you're using FF, frex, it will *not* render SVG in HTML unless you're using one of the nightlies and have the html5 parser turned on. That's probably why you're having to serve it as text/xml. |
| 03:58 | <bartek> | I'm using Chromium nightly for Ubuntu. Not sure if it does it right. It works on most sites, just had to use t ext/xml on my localhost |
| 04:03 | <roc> | webkit doesn't support SVG in text/html |
| 07:02 | <cardona507> | I am working with appcache - and I think I got it , but when I disconnect from the network my browser has all of the tabs that were open in it's cache -so I can't tell if appcache worked or not. Can someone recommend a way to test my appcache? |
| 07:14 | <annevk42> | load one image or so over the network, do not set the online whitelist flag, and do not mention the image in the manifest, then load the app and then reload, if the image is still there there's a bug |
| 07:14 | <annevk42> | (iirc) |
| 07:24 | <cardona507> | thanks annevk42 |
| 08:51 | <annevk2> | hmm, should I rename CSSOM to "Web DOM Style" or some such so the part on the CSSOM can actually be called that way? |
| 08:54 | <annevk2> | I think I'll just called it "CSS Style Sheets" which is somewhat double, but consistent as well |
| 08:55 | <robertnyman> | About meta tag usage.... |
| 08:55 | <robertnyman> | If I use the old way of specifying it, (<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">) which is still supported, it validates fine with the validator at W3C |
| 08:56 | <robertnyman> | But if I use the new version (<meta charset="UTF-8">), it only tentatively validates, since it claims it can't find the character encoding |
| 08:56 | <robertnyman> | Is this something to be implemented by the validator? Should I report it as a bug? |
| 08:57 | <annevk2> | sounds like a bug of some kind, yes |
| 08:57 | <annevk2> | what does validator.nu do? |
| 08:57 | <robertnyman> | From what I could see there, it just said it was valid in both cases |
| 08:57 | <robertnyman> | Should try it without character encoding at all, to see if it even checks that |
| 08:59 | <annevk2> | if it can't find the encoding it's a bug |
| 08:59 | <annevk2> | unless you put it in the wrong place, but then it should report that too, so it's a bug either way |
| 09:00 | <robertnyman> | Hmmm... |
| 09:00 | <robertnyman> | Well, if I check by URL (e.g. http://robertnyman.com), it seems to validate fine |
| 09:01 | <annevk2> | anyone a good name for a section that defines .style, getComputedStyle, and possibly new friends? |
| 09:01 | <robertnyman> | But if I validate by text field at validator.nu, it doesn't consider character encoding at all... |
| 09:01 | <robertnyman> | Oh, well, I need to make some consistent sense out of this |
| 09:01 | <robertnyman> | Thanks! |
| 09:03 | <gsnedders|work> | robertnyman: That's because you specify a series of characters, not a series of bytes (with an associated character encoding) |
| 09:04 | <robertnyman> | Ah, right |
| 09:22 | <jgraham> | annevk2: If you call it CSS Style Sheets then you will get nothing but complaints that it means Cascading Style Sheets Style Sheets |
| 09:22 | <annevk2> | I'll just point to CSSStyleSheet |
| 09:24 | <hsivonen> | sigh. I broke frames. |
| 09:27 | <hsivonen> | I need one of those "Have you stopped breaking the Web yet?" t-shirts. |
| 09:33 | <gsnedders|work> | hsivonen: What? Where? |
| 09:34 | <hsivonen> | gsnedders|work: I only broke frames locally. I think the t-shirt is on the level of a suggestion on twitter at this point. |
| 09:34 | <gsnedders|work> | ah. |
| 09:34 | <gsnedders|work> | Aww… |
| 10:04 | <hsivonen> | HTML5 doesn't have a normative reference to any flavor of RDFa, right? |
| 10:04 | <hsivonen> | at least I can't find the string "RDFa" in the spec |
| 10:04 | <Hixie> | no |
| 10:04 | <hsivonen> | ok |
| 10:10 | <jgraham> | Hixie: The encoding table in the spec isn't really based on data it's based on other peoples guesses |
| 10:11 | <Hixie> | it's based on what firefox does |
| 10:13 | <jgraham> | Yeah and what Firefox does is based on the individual localisers right? And presumably they have not actually run studies to determine the most useful encoding, they have just guessed |
| 10:13 | <Hixie> | i expect there's been more of a feedback loop than that, but sure |
| 10:14 | <Hixie> | i would be more than happy to use better data |
| 10:18 | <jgraham> | Hixie: I think the fact the Welsh suggests UTF-8 rather than Windows-1252 even though, presumably, most welsh speaksers will primarilly interact with English-language content is evidence of a poor feedback loop |
| 10:18 | <hsivonen> | jgraham: it's quite possible that the younger localizations or the ones with a less populous user base reflect more the choices of an individual localizer rather than a feedback loop converging on what works best with legacy content |
| 10:19 | <hsivonen> | jgraham: my guess about how UTF-8 has ended up as default is the same as Leif's, but that's just a guess |
| 10:19 | <Hixie> | jgraham: i'm happy to use better data if you have it. For example, what does Opera's Welsh localisation use? |
| 10:19 | <Hixie> | or IE's? |
| 10:19 | <jgraham> | What is Leif's guess? |
| 10:20 | <hsivonen> | jgraham: Leif guessed that it's motto-based |
| 10:20 | <Hixie> | are there bugs filed by Welsh users? |
| 10:20 | <Hixie> | etc |
| 10:20 | jgraham | can't remember or didn't folloow |
| 10:20 | <jgraham> | motto-based? As in "unicode is good"? |
| 10:20 | <hsivonen> | jgraham: right |
| 10:21 | <Hixie> | (i could probably be convinced to just remove all the utf-8 cases in favour of win1252, but if you want that, file a bug) |
| 10:21 | <jgraham> | I can't see any evidence that unicode covers the Welsh digraphs |
| 10:21 | <Hixie> | anyway, gotta go |
| 10:21 | <Hixie> | bbl |
| 10:21 | <jgraham> | so it makes no sense to use UTF-8 as the default rather than Win-1252 |
| 10:21 | <hsivonen> | I'm kinda curious enough that I might file bugs against the Welsh, Romanian and Vietnamese localizations asking for rationale |
| 10:23 | <hsivonen> | I'm inclined to think nothing should default to UTF-8 to force authors to label their UTF-8 content |
| 10:25 | <jgraham> | Although it seems that they use optional accented letters that might not be covered by Win-1252. Nevertheless I have great difficulty believeing that the material consumed by Welsh-language-browser-users is not primarilly English |
| 10:25 | <hsivonen> | I was very surprised to find that the Vietnamese localization didn't default to the Windows-* code page for Vietnamese |
| 10:26 | <hsivonen> | fwiw, the Firefox localization have other oddities like Swedish defaulting to chardet on. |
| 10:26 | <hsivonen> | which is clearly bogus. |
| 13:11 | <gsnedders|work> | Philip`: ping |
| 13:52 | <Philip`> | gsnedders|work: Space Invaders |
| 13:52 | <gsnedders|work> | Philip`: So how long do I have to wait? |
| 13:53 | <Philip`> | gsnedders|work: For what? |
| 13:53 | <gsnedders|work> | Philip`: For you to properly pong me? :P |
| 13:54 | <Philip`> | gsnedders|work: Oh, sorry, I just got mixed up a bit |
| 13:54 | <Philip`> | I'll be away in a small number of minutes, but am here now |
| 13:54 | <gsnedders|work> | Philip`: How did you organize the dotbot data such that you could easily run regex and get the URL of the page? |
| 13:58 | <Philip`> | gsnedders|work: All I did was have a four-byte URL length int, then the URL string, then a four-byte response length, then the response, then repeat |
| 13:59 | <Philip`> | and alternated between 16 output files to allow some parallelism in processing (which the grep tool doesn't use) |
| 13:59 | <Philip`> | and gzipped all the files |
| 13:59 | <gsnedders|work> | Philip`: So how do you run regex? Via some script? |
| 13:59 | <Philip`> | and then wrote some Java code that would load all the files and run regexps |
| 13:59 | <gsnedders|work> | k |
| 14:00 | <Philip`> | (and parse the HTTP headers etc) |
| 14:02 | <Philip`> | (The initial file format conversion / splitting was just to make things easier to parse efficiently in Java, and to allow parallel processing on separate chunks of pages) |
| 14:36 | <TabAtkins> | Woah, woah, woah. " No one, not even those who support RDF/RDFa has suggested dumping Microdata." At what point did Shelley switch from being misleading to outright lying? |
| 14:38 | <hsivonen> | TabAtkins: citation-needed for suggestion of dumping microdata. |
| 14:38 | <TabAtkins> | Hmm, I'll go look for it. |
| 14:50 | <TabAtkins> | All right, point. Nowhere that I can find does Shelley explicitly say that she wants to dump Microdata. There is the point where she ragequit the group because of Microdata, and several places where she expressed that it was useless or similar, but nowhere where she actually said something along the lines of "We should kill Microdata". |
| 14:57 | <hsivonen> | wow. I was unaware that PICS is the oldest non-superceded REC |
| 14:58 | hsivonen | wonders what PICS 1.0 was |
| 14:58 | <hsivonen> | if 1.1 is from 1996 |
| 15:13 | <Lachy> | TabAtkins, Shelley and others have advocated the position that Microdata should be removed from HTML5 and developed in its own independent spec, but I suspect such people have avoided directly saying that it should be dropped |
| 15:13 | <TabAtkins> | Yeah, that's the line of the hour. |
| 15:14 | <Lachy> | though, I suspect that ultimately, they want the end result to be that Microdata dies off in favour of RDFa |
| 15:15 | <Lachy> | whereas, I don't have a problem with saying directly that I think RDFa should just die. |
| 15:15 | <annevk2> | don't assume bad faith |
| 15:17 | <MikeSmith> | amen to what annevk2 said |
| 15:17 | <Lachy> | I'm not assuming bad faith. |
| 15:18 | <MikeSmith> | Lachy: no, you just "suspect" it |
| 15:18 | <MikeSmith> | clearly that's very different from assuming it |
| 15:18 | <MikeSmith> | my bad |
| 15:18 | <TabAtkins> | I don't think bad faith is involved in wanting one option to win among multiple. |
| 15:19 | <annevk2> | TabAtkins, you're missing the point |
| 15:19 | <Lachy> | what I said had nothing to do with assuming/suspecting bad faith. It's just the logical conclusion from the fact that they openly don't support Microdata and are strongly pushing RDFa instead. |
| 15:19 | <annevk2> | TabAtkins, assuming bad faith is not about you, but what you think the plans of the other party are |
| 15:20 | <TabAtkins> | annevk2: Indeed, and I think I know exactly what their plans are, and I don't have a problem with that. I do have a problem with certain people attempting to profess neutrality when they are advocates of a particular side, but that's it. |
| 15:20 | <othermaciej> | it seems clear that most people asking for Microdata to be removed from the main spec have a preference for RDFa and would in some sense like it to win |
| 15:20 | <annevk2> | Lachy, voicing support for A and not B does not mean you want B to die off |
| 15:20 | <annevk2> | that's not at all logical |
| 15:20 | <othermaciej> | but it seems reasonable to ask for RDFa and Microdata to be on a level playing field |
| 15:21 | <othermaciej> | and that request is not equivalent to blocking Microdata and doesn't necessarily imply a secret desire to kill it |
| 15:21 | <othermaciej> | so it's a request that should be considered on the merits |
| 15:22 | <othermaciej> | on the other hand, I also think it's a fair position to say that Microdata is better than RDFa and *should* be given the advantage, or to argue the opposite |
| 15:22 | <Lachy> | sure, but that's not bad faith either. Bad faith suggests that they have a malicious motive with what they're doing to undermine some work, and that's not what they're doing. |
| 15:22 | <othermaciej> | but arguments of the form "A is better than B so we should make it win" don't tend to use any rationale that would be convincing to the other side |
| 15:23 | <othermaciej> | even potentially convincing |
| 15:23 | <othermaciej> | whereas "let's put these on an even footing for reasons of fairness" is something you could in theory agree with whether you prefer A or B |
| 15:24 | <hsivonen> | I think accusing people of lying without citing evidence is improper, but I don't think it would be bad faith on the part of the RDFa proponents if they openly wanted to kill Microdata if they believed RDFa is better for the Web and Microdata is bad for the Web. |
| 15:24 | <othermaciej> | it would not be in bad faith to openly pursue that goal |
| 15:24 | <TabAtkins> | Well, wait a moment. That's not something you can agree with in general. Most proposals should *not* be on an even footing, because one is clearly better than the other. |
| 15:25 | <othermaciej> | it could be seen as bad faith to claim to just want fairness but only as a preliminary step to a secret goal of defeating the opposition in some other way |
| 15:25 | <othermaciej> | TabAtkins: I'm not saying that argument is always persuasive regardless of the specific A and B or the person considering the argument |
| 15:26 | <jgraham> | Once people are thinkiong in terms of opposition and defeating you have lost anyway |
| 15:26 | <annevk2> | btw, I forgot but the document.all stuff also applies to .style.filter |
| 15:26 | <TabAtkins> | othermaciej: All right, just making sure. Falsely equating unequal things can make bad stuff happen. |
| 15:26 | <hsivonen> | jgraham: haven't we had that situation ever since 2004 with the WHATWG and the XHTML2 WG? |
| 15:27 | <othermaciej> | just that it's something that *could* be persuasive, at least if you think reasonable people can disagree about A vs. B, even if you prefer one or the other |
| 15:28 | <othermaciej> | whereas "B is better" has very little chance of persuading A advocates, or at least in this debate I have yet to see anyone shift their position based on such arguments |
| 15:28 | <TabAtkins> | jgraham: Conflict is a necessary part of development. Opposition and defeat *are* a part of every useful process. It shouldn't be a core resolution method to every problem (compromise is often useful), but nor should it be ignored. |
| 15:28 | <hsivonen> | annevk2: whoa, whoa. are there other undetectable objects besides document.all? across all of Gecko, WebKit and Opera? |
| 15:28 | <othermaciej> | hsivonen: in WebKit, document.all and style.filter are the only two objects that masquerade as undefined |
| 15:28 | <hsivonen> | does Gecko have a magic style.filter? |
| 15:28 | <othermaciej> | (style.filter returns a subclass of the ECMAScript built-in String class that masquerades as undefined) |
| 15:29 | <annevk2> | hsivonen, Gecko doesn't do filter |
| 15:29 | <othermaciej> | I think Gecko does not have style.filter at all yet, but a Gecko developer recently asked me what we do for SVG CSS properties in the CSSOM, including filter, and I told him |
| 15:29 | <annevk2> | hsivonen, it's hidden in Opera too |
| 15:29 | <jgraham> | TabAtkins: Sure. But it is helpful if the conflict is at a level where it can be resolved by technical merit rather than something else |
| 15:29 | <annevk2> | I told the SVG WG they should rename it cssFilter just like cssFloat |
| 15:29 | <annevk2> | but that didn't happen :/ |
| 15:29 | <hsivonen> | Is this about SVG not carefully avoiding names that IE has already taken? |
| 15:29 | <jgraham> | (i.e. where people are prepared to accept technical arguments.) |
| 15:30 | <annevk2> | hsivonen, yes |
| 15:30 | <hsivonen> | annevk2: well, that sucks. Why didn't WebKit and Opera devs just require SVG to change? |
| 15:31 | <othermaciej> | we considered just dropping style.filter from the DOM entirely |
| 15:31 | <othermaciej> | at the time this came up, the SVG WG was less open to consideration of pragmatic concerns for browsers than it is now |
| 15:32 | <hsivonen> | :-( |
| 15:32 | <othermaciej> | I believe the CSS WG even asked the SVG WG not to use a CSS property named 'filter' in the first place, due to collision with the proprietary IE property and the resulting potential for problems |
| 15:32 | <othermaciej> | but SVG WG rejected that comment |
| 15:32 | <othermaciej> | I don't know if there is a lot of content depending on style.filter, so it may not be too late to change |
| 15:33 | <othermaciej> | I can't remember if there was a specific reason we didn't want to just rip it out entirely |
| 15:33 | <zcorpan_> | can we still change style.filter to something sane? |
| 15:33 | <gsnedders|work> | "The specifications the Web is built upon are often rather crappy" — wilhelm |
| 15:34 | <gsnedders|work> | (sorry, I found that amusing because normally I only hear really vulgar things about specs or trying-hard-to-be-polite-while-saying-they-suck things) |
| 15:35 | <annevk2> | hsivonen, apparently Mozilla didn't agree to change the name... |
| 15:37 | <hsivonen> | annevk2: interesting situation. |
| 15:39 | <annevk2> | yes :) |
| 15:45 | <svtech> | gsnedders|work, and the technologies used by most browsers are also rather crappy. |
| 15:46 | <svtech> | Why can't we still smooth zoom our web pages or enjoy hardware accelerated rendering :( |
| 15:46 | <othermaciej> | annevk2: Mozilla didn't agree to change the name of a property they still haven't implemented? |
| 15:49 | <gsnedders|work> | svtech: Opera is working on a hardware accelerated backend for rendering |
| 15:53 | <annevk2> | othermaciej, that's what Erik told me, yes |
| 15:53 | <annevk2> | othermaciej, prolly over Brendan Eigh's dead body, too :) |
| 15:54 | <annevk2> | s/gh/ch/ oop |
| 15:54 | <annevk2> | s |
| 15:54 | <othermaciej> | annevk2: we should probably propose changing it again so we can get rid of the stupid undetectability hack |
| 15:54 | <othermaciej> | annevk2: because for style.filter, it's completely a self-inflicted wound |
| 15:56 | <annevk2> | yes, I said so to Erik, but then he had to go |
| 15:56 | <Philip`> | svtech: I've found that I can effectively emulate smooth zooming without any additional hardware requirements, by moving my head backwards and forwards |
| 15:58 | Philip` | wonders how much more effective hardware acceleration could be if it was designed for web browsers rather than for games |
| 16:02 | <annevk2> | where in HTML5 is it defined when layout is supposed to be done? |
| 16:04 | <zcorpan_> | annevk2: event loop? |
| 16:05 | <zcorpan_> | "If necessary, update the rendering or user interface of any Document or browsing context to reflect the current state." |
| 17:13 | <Philip`> | http://www.w3.org/News/2009#entry-6521 - hmm, I had to look at the image's alt text before I could figure out what the image meant |
| 17:14 | <JoePeck> | Philip`: lol =) |
| 18:23 | <mpilgrim> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7542 |
| 18:27 | <mpilgrim> | " |
| 18:27 | <mpilgrim> | One way to resolve this issue, and ensure its closure before Last Call is |
| 18:27 | <mpilgrim> | to remove the Microdata section, either into its own spec, or entirely. |
| 18:27 | <mpilgrim> | " |
| 18:28 | <mpilgrim> | @Lachy, @hsivonen, @TabAtkins |
| 18:29 | <Philip`> | Is that in relation to "something along the lines of "We should kill Microdata""? If so, I don't see how "X is possible" implies "We should do X" |
| 18:32 | <mpilgrim> | http://lists.w3.org/Archives/Public/public-html/2009May/0074.html |
| 18:32 | <mpilgrim> | "There are exactly two options for metadata going forward ... |
| 18:32 | <mpilgrim> | The options |
| 18:32 | <mpilgrim> | are microformats, and RDFa. |
| 18:32 | <mpilgrim> | " |
| 18:34 | <TabAtkins> | I'm heading to lunch - I'll respond later. |
| 18:37 | <mpilgrim> | http://lists.w3.org/Archives/Public/public-html/2009May/0069.html |
| 18:38 | <mpilgrim> | "To be blunt, I'm only interested in this specification because I hope to see it advance two other specifications that have been hindered by their XHTML-only state: SVG and RDFa." |
| 18:41 | <annevk42> | I'm getting particularly bored with all the non-constructive meta discussions |
| 18:42 | <annevk42> | On the upside I am much better trained now at spotting and ignoring them |
| 18:43 | <Philip`> | Are there ever constructive meta discussions? |
| 18:44 | <annevk42> | I had one at TPAC last year about what needs to be done to solve the HTML to AT mapping issue |
| 18:44 | <annevk42> | And I've had several with members of the i18n WG |
| 18:46 | <mpilgrim> | "meta is murder": http://www.codinghorror.com/blog/archives/001282.html |
| 18:49 | <mpilgrim> | (which is not an argument against all meta discussions, just an argument for having them somewhere else) |
| 18:50 | <gsnedders> | jgraham: Can you push your fixes to html5lib? |
| 19:38 | <shelleyp> | annevk2: by your disinterest in discussions about metadata, which is what Microdata is, I think we can take it that you agree with removing it from HTML5 |
| 19:40 | <shelleyp> | In fact, by much of the disinterest I see in this group, I believe we can achieve this goal by lazy consensus, and then we'll never need discuss it again |
| 19:42 | <TabAtkins> | shelleyp: I am interested in metadata at least somewhat, and feel that Microdata is a superior solution which deserves to be in the spec. (I'm still at lunch, though, so if you reply I'll be a while in seeing it.) |
| 19:42 | <othermaciej> | hi shelleyp |
| 19:42 | <shelleyp> | You need to reply to the email list |
| 19:42 | <shelleyp> | Hi Maciej |
| 19:43 | <shelleyp> | TabAtkins: sorry, I think you need to reply to the email lists. That way a positive note can be recorded in favor of keeping microdata |
| 19:43 | <othermaciej> | definitely anyone who thinks that Microdata should stay in the spec should post their position and rationale to public-html |
| 19:43 | <shelleyp> | othermaciej: agree. It would be most helpful |
| 19:44 | <othermaciej> | if there are no strong reasons given for including it in HTML5, then a Change Proposal to remove it would likely succeed by default |
| 19:44 | <shelleyp> | othermaciej: agree with that also. |
| 19:45 | <othermaciej> | (I haven't closely reviewed the reasons for keeping it in that people posted so far) |
| 19:46 | <shelleyp> | othermaciej: I've seen two, but could be wrong. One is all markup should stay together, the second RDFa is bad |
| 19:46 | <shelleyp> | othermaciej: but the RDFa is bad argument isn't pertinent to keeping Microdata |
| 19:47 | <othermaciej> | Jonas said: "I think microformats are a very interesting feature and important enough to keep in the main specification" but he didn't expand on that in more detail |
| 19:47 | <shelleyp> | othermaciej: microformats? |
| 19:47 | <jgraham> | gsnedders: I'll push now (just go back from Swedish) |
| 19:47 | <othermaciej> | I assume he misspoke |
| 19:48 | <othermaciej> | I cut & pasted from his email |
| 19:48 | <shelleyp> | othermaciej: I think he might have. At the same time, though, there has been a conflation between microdata and microformats |
| 19:48 | <shelleyp> | othermaciej: we should leave microformats totally out of the discussion, because its a completely independent effort |
| 19:49 | Philip` | suggests renaming microdata to something that doesn't contain "micro", to avoid confusion |
| 19:49 | <othermaciej> | he also said he thinks Microdata is "an integral part of the HTML language" though without much further justification |
| 19:49 | <othermaciej> | I think people citing microformats either misspoke (I think that's the case with Jonas) or were drawing functional comparisons |
| 19:49 | <shelleyp> | othermaciej: That's kind of why I want to move away from the RDFa is bad argument. That's not a viable reason for keeping Microdata. |
| 19:50 | <othermaciej> | Philip Jägenstedt said he thinks microdata should be included because "it is a fairly simple syntax/model and a DOM interface which should be familar to web developers while still solving real use cases" |
| 19:50 | <shelleyp> | othermaciej: For instance, ask a person who likes RDFa why, they won't answer "Because Microdata is so bad" |
| 19:50 | <othermaciej> | I think some people failed to consider the "other applicable specifications" clause |
| 19:51 | <shelleyp> | othermaciej: That explains why Microdata could exist, but not necessarily why it should stay in the HTML spec |
| 19:51 | <othermaciej> | shelleyp: I'm quoting the reasons here, not necessarily endorsing them |
| 19:52 | <shelleyp> | othermaciej: Sure, I'm kind of just ruminating on the statements. I appreciated that Philip did provide specifics |
| 19:52 | <othermaciej> | a lot of people did make arguments of roughly the form "Microdata is better than RDFa" |
| 19:53 | <shelleyp> | othermaciej: what is the "other applicable specifications" clause? |
| 19:53 | <othermaciej> | I tend to agree that's not a strong reason by itself to put it in the main spec |
| 19:53 | <othermaciej> | shelleyp: basically that HTML5 allows extension specifications to define additional elements and attributes |
| 19:53 | <othermaciej> | shelleyp: so the argument that all the element and attributes have to be in the main spec is not correct, at least on a technical level |
| 19:54 | <othermaciej> | see http://dev.w3.org/html5/spec/Overview.html#semantics-0 |
| 19:54 | <othermaciej> | "Authors must not use elements, attributes, and attribute values that are not permitted by this specification or other applicable specifications." |
| 19:55 | <othermaciej> | and the link to http://dev.w3.org/html5/spec/Overview.html#other-applicable-specifications (scroll up a bit) |
| 19:55 | <shelleyp> | othermaciej: that would definitely cover Microdata in a separate spec. |
| 19:55 | <othermaciej> | indeed, and it also covers RDFa in a separate spec |
| 19:56 | <othermaciej> | so there's no technical obstacle to having some elements and attributes defined in a separate spec |
| 19:56 | <jgraham> | It seems to me that "RDFa is bad" is a valid reason for having an asymmetry between RDFa and Microdata and not having such an asymmetry has been one of the reasons stated for removing Microdata from the spec |
| 19:56 | <Philip`> | I suppose it would also cover <em> and <object> and hundreds of other things in separate specs |
| 19:56 | <othermaciej> | my personal feelings on this issue are: |
| 19:57 | <othermaciej> | - I think Microdata is technically a better solution for its use cases than RDFa |
| 19:57 | <othermaciej> | - I expect people will continue to use RDFa in text/html no matter what we say, so it may as well have a proper spec |
| 19:58 | <jgraham> | (so I think that if you want to remove arguments that depend on the technical merits of Microdata vs RDFa you need to do so symmetrically; that is you need to argue for removal on its own merits and not because of some sense of fairness) |
| 19:58 | <othermaciej> | - I think there's enough reasonable difference of opinion on the relative merits of RDFa and Microdata that it will make the HTML WG's life much easier to put them on an even footing, and let them compete in the market on their own merits |
| 19:59 | <othermaciej> | I don't really want to argue these points too strongly in the thread, because I'd like to be able to referee the discussion reasonably |
| 19:59 | <othermaciej> | I think people should consider the following thoughts: |
| 19:59 | <shelleyp> | othermaciej: I agree. And you're right, this discussion should be happening in the email list. |
| 20:01 | <othermaciej> | a) Can you think of a form of the position you disagree with that casts in in the best possible light, and is something you could almost consider agreeing with? Addressing the strongest form of an argument tends to be more persuasive (or who knows, you may change your own mind.) |
| 20:01 | <othermaciej> | b) Can you think of arguments for your position that might have a chance of seeming reasonable from the point of view of people coming to the conversation with different premises? |
| 20:01 | <shelleyp> | othermaciej: a little offputting to have people say, in effect, shut up on this subject in the email list, when the WG chairs asked for this discussion |
| 20:02 | <shelleyp> | othermaciej: those are good points |
| 20:03 | <othermaciej> | in technical disputes, it's easy to fall to the temptation to come up with the weakest form of your opponent's position instead of the strongest, and to preach to the choir instead of looking at ways to persuade people who disagree |
| 20:03 | <othermaciej> | heck, I'm sure I do that myself at times |
| 20:03 | <othermaciej> | but the above two ideas are things I thought of in the course of discussion threads that got way more heated than they were ever supposed to |
| 20:04 | gsnedders | just generally accepts that rhetoric is something he isn't good at and stays out of technical disputes… which is somewhat problematic in this line of work :) |
| 20:04 | <gsnedders> | 9 |
| 20:05 | <gsnedders> | (I was actually going to email something about RDFa and Microdata tomorrow, though) |
| 20:05 | <Philip`> | (If the disputes require rhetoric, it sounds like they're not really technical disputes) |
| 20:05 | <othermaciej> | I think engaging in this discussion is fine, as long as people can keep it about the issues and avoid being insulting and losing their tempers |
| 20:06 | <othermaciej> | I think mostly people are doing ok in that regard |
| 20:06 | <othermaciej> | Philip`: it's nice to think that technical issues can have completely objective answers, but that's only really true if the parties to the discussion have the same goals and values |
| 20:07 | <gsnedders> | Philip`: But rhetoric is generally just the art of persuasive speaking, how you are persuasive is beside the point |
| 20:07 | <othermaciej> | WHATWG tends to have shared goals and values because of self-selection effects |
| 20:07 | <Philip`> | othermaciej: Maybe I'm interpreting "technical issue" differently |
| 20:07 | <othermaciej> | HTML WG has people with different goals and values, and is not allowed to just ignore people who dissent from a particular point of view |
| 20:09 | <shelleyp> | Philip: there can be two equally good technical choices, and sometimes the only way a choice can be made is to provide a strong argument |
| 20:09 | <shelleyp> | Philip: based on interest, passion, existing work, whatever. Not everything can always reduce down to purely technical issues |
| 20:09 | jgraham | wishes he was using mq |
| 20:10 | <shelleyp> | Anyway, good arguments here, I hope to see them in the mailing list ;-) |
| 20:18 | <Philip`> | jgraham: I can see an easy solution to that: Start using mq |
| 20:21 | <jgraham> | Philip`: It's not a solution that helps rectroactively. So I guess I was imprecise. I wish I had previosuly been using mq |
| 20:23 | <Philip`> | jgraham: Can't you just convert your previous commits into mq patches and then delete the commits? |
| 20:23 | <jgraham> | gsnedders: changes now pushed. I get 3 fails and 1 error, 2 of which are in bs |
| 20:23 | <Philip`> | s/commits/revisions/ or whatever they're called |
| 20:24 | <jgraham> | (one is the missing feature one is an encoding detection thing that I should check out) |
| 20:24 | <jgraham> | (of the others that is) |
| 20:24 | <jgraham> | Philip`: Maybe. Still I solved the problem for now |
| 20:27 | <gsnedders> | oo, nice. |
| 20:27 | <gsnedders> | I get 1 fail and 1 error |
| 20:33 | <Dashiva> | element . properties - If the element has an item attribute, returns an HTMLPropertyCollection object (...) |
| 20:33 | <Dashiva> | "an item attribute" seems a bit vague. Is it supposed to mean any of itemscope/itemid/itemtype/etc? |
| 20:36 | gsnedders | sighs, realizing his copy of the SGML handbook is in Scotland |
| 20:36 | gsnedders | realizes the XML subset is probably enough |
| 20:38 | <TabAtkins> | Man, Shelley left. shelleyp, if you're reading this from the logs: so far I don't have any good reason to chime in on the thread, because jgraham and hsivonen have expressed my opinions adequately. If there's a poll I'll speak up, but for now all the technical points I might make have already been made by others, and are being argued sufficiently. |
| 20:40 | <Philip`> | gsnedders: Just make things up and say they're what the SGML handbook says, nobody's going to bother to check |
| 20:45 | <gsnedders> | Philip`: :) |
| 20:46 | <jgraham> | gsnedders: Did you pull html5lib? Does it work? |
| 20:46 | <gsnedders> | jgraham: As I said above, 1 pass and 1 error |
| 20:47 | <gsnedders> | jgraham: Do you happen to know if we have a copy of the SGML spec at work? |
| 20:48 | <jgraham> | gsnedders: Oh well I wasn't reading above |
| 20:49 | <jgraham> | gsnedders: No idea about SGML. I can't see why we would since we have never shipped anything SGML based that I know of |
| 20:49 | <Handcrafted> | I have a question about the storage spec |
| 20:49 | <gsnedders> | jgraham: I dunno. We implemented some more eccentric stuff in our HTML parser than anyone else. We might. |
| 20:49 | <Handcrafted> | What is the current state of the persisten, cross session sql storage? |
| 20:51 | <Dashiva> | Philip`: The SGML handbook says you can't make things up or you'll explode |
| 20:52 | <Dashiva> | Anyone want to chime in on my microdata question from earlier? |
| 20:53 | <jgraham> | Dashiva: What was the question? |
| 20:53 | <Dashiva> | [21:42:11] <Dashiva> element . properties - If the element has an item attribute, returns an HTMLPropertyCollection object (...) |
| 20:53 | <Dashiva> | [21:42:32] <Dashiva> "an item attribute" seems a bit vague. Is it supposed to mean any of itemscope/itemid/itemtype/etc? |
| 20:54 | <jgraham> | Oh yeah. I don't know what you're quoting |
| 20:54 | <Dashiva> | http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata-dom-api |
| 20:55 | <jgraham> | Dashiva: I think that is a bug |
| 20:55 | <jgraham> | But I'm not enirely sure |
| 20:56 | <Dashiva> | Should be itemscope instead of item? |
| 20:56 | <jgraham> | Yes |
| 21:00 | <Hixie> | http://twitter.com/timbray/status/4890085030 - am i the only one _not_ seeing htat? |
| 21:01 | <roc> | jgraham, Philip`: hg qimport -r tip |
| 21:01 | <othermaciej> | Hixie: I believe they have now fixed it |
| 21:02 | <Hixie> | oh it wasn't intentional? |
| 21:02 | <othermaciej> | Hixie: it was intentional, there was some pushback though |
| 21:02 | <Hixie> | ah |
| 21:02 | <othermaciej> | Hixie: I can post a screenshot of what the changed version looked like - I have a cached copy of HTML4.01 |
| 21:02 | <Hixie> | nah, it's ok |
| 21:02 | <Dashiva> | Hixie: Comment on the microdata lines just before you returned? |
| 21:03 | <othermaciej> | Hixie: basically they added the header and footer of the new w3.org site |
| 21:03 | <Hixie> | Dashiva: should be itemscope. file a bug with the widget. |
| 21:03 | <othermaciej> | Hixie: moved SotD to the bottom |
| 21:03 | <Hixie> | Dashiva: (and thanks) |
| 21:03 | <othermaciej> | Hixie: added an odd new intro section |
| 21:03 | <othermaciej> | Hixie: broke some custom styling on some of the RECs |
| 21:03 | <Hixie> | i could see why people might get upset |
| 21:04 | <othermaciej> | where was some consternation on chairs |
| 21:04 | <gsnedders> | jgraham: Is there any reason why <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">foo doesn't round-trip in html5lib? |
| 21:05 | <roc> | othermaciej: were specific compatibility issues discovered with detectable support for style.filter? |
| 21:05 | <othermaciej> | roc: yes |
| 21:05 | <jgraham> | gsnedders: Yes. Don't know what it is though |
| 21:05 | <othermaciej> | roc: sites broke |
| 21:05 | <gsnedders> | jgraham: Like, is it deliberate it does not? |
| 21:05 | <Dashiva> | I wonder what reports were envisioned when the "May be seen by hundreds of peopel" was added :) |
| 21:05 | <othermaciej> | specifically, there were several sites that set opacity in the following way: |
| 21:05 | <jgraham> | gsnedders: Not afaik. What does it roundtrip to and with which treebuilder? |
| 21:06 | <othermaciej> | - if the style.filter property exists, then assume you should use IE DirectX filters to set opacity; else if style.mozOpacity is present use that; else if style.webkitOpacity is present use that; else if style.opacity is present use that |
| 21:06 | <gsnedders> | jgraham: <!doctype html>foo. Treebuilder is irrelevant, as the serializer never outputs public/systemid (though all the code is there to even pass it to the serializer!) |
| 21:06 | <roc> | ok, thanks. and who was it at Mozilla who told you we wouldn't rename it? |
| 21:06 | <othermaciej> | roc: which, of course, is totally backwards, but there were enough of these sites that we decided to surrender |
| 21:06 | <gsnedders> | jgraham: I have patch ready to go |
| 21:06 | <othermaciej> | roc: no one from Mozilla told me that |
| 21:06 | <jgraham> | gsnedders: Feel free to fix it if you want. I din't write the serializer |
| 21:07 | <othermaciej> | roc: Anne said that Erik told him that someone from Mozilla was against renaming it |
| 21:07 | <jgraham> | gsnedders: Needs tests though |
| 21:07 | <roc> | ah |
| 21:07 | <othermaciej> | roc: I think we may have brought it up with the SVG WG at the time, but I don't remember for sure if we did, or if so what the outcome was |
| 21:07 | <roc> | well, I agree to use a different name |
| 21:07 | <roc> | problem solved |
| 21:07 | <othermaciej> | me too! |
| 21:07 | <othermaciej> | what specs (if any) should be changed? |
| 21:07 | jgraham | loves specs chinese whispers |
| 21:08 | <Handcrafted> | I'd like to re-ask my question: What is the current state of the persisten, cross session sql storage? |
| 21:08 | <roc> | no idea |
| 21:08 | <jgraham> | Handcrafted: What do you mean "state"? |
| 21:08 | <gsnedders> | jgraham: That means changing the test format. |
| 21:08 | <othermaciej> | Handcrafted: it's implemented in Safari, coming soon in Chrome, Opera has announced plans to support, Mozilla doesn't like it, no clear statement either way from Microsoft |
| 21:09 | <Handcrafted> | jgraham: Well, it seems like it has been removed from the spec. I can't find it anywhere |
| 21:09 | <Handcrafted> | othermaciej: Same as I said to jgraham |
| 21:10 | <jgraham> | gsnedders: Really? You can always just make a one-off test using the normal unittest api if you like |
| 21:10 | <jgraham> | Handcrafted: yeah it is in a seperate file now |
| 21:10 | <othermaciej> | Handcrafted: it's in a separate spec |
| 21:10 | <gsnedders> | jgraham: The one reason, apart from tests that makes me weary about committing it, is I'm not entirely sure what the SGML format of DOCTYPEs is |
| 21:10 | <gsnedders> | http://dev.w3.org/html5/webstorage/ |
| 21:11 | <jgraham> | gsnedders: Why do you care? I would expect, at best, to match XML |
| 21:11 | <gsnedders> | database storage is in yet another spec now |
| 21:11 | <jgraham> | Yay for splitting out specs |
| 21:11 | <Handcrafted> | I don't know if it was to me, but that docuemnt isn't about the sql |
| 21:11 | <gsnedders> | jgraham: XML doesn't allow <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
| 21:11 | <Hixie> | Handcrafted: if you like it in the same spec as HTML, you can find all the stuff that used to be in HTML5 here: http://www.whatwg.org/specs/web-apps/current-work/complete.html |
| 21:12 | <Handcrafted> | Hixie: Thanks! |
| 21:12 | <Hixie> | 13-specs-in-1 |
| 21:12 | <gsnedders> | Hixie: Add more specs, plz. |
| 21:12 | <jgraham> | gsnedders: Hmm. I would prefer if we always emitted a polyglot-friendly doctype |
| 21:13 | <gsnedders> | jgraham: Then I really need to check, for the sake of DOCTYPEs like that, what SGML says… |
| 21:13 | <gsnedders> | jgraham: The test format currently uses a list, 0th member is token type, and for the DOCTYPE token it has only one more, the element name. |
| 21:14 | <gsnedders> | jgraham: I guess I could add more without breaking anything |
| 21:14 | <jgraham> | gsnedders: Why? It seems much easier just to do what XML allows rather than sticking pedantically to some spec that no-one even has and no relevant UA ever implemented |
| 21:14 | <gsnedders> | jgraham: Because people _want_ to output valid HTML 4.01 |
| 21:15 | <gsnedders> | jgraham: If you put anything in that is possible in a polyglot document, you will get something polyglot out |
| 21:15 | <gsnedders> | I don't think it's an issue. |
| 21:16 | <gsnedders> | hsivonen: you around? |
| 21:19 | <gsnedders> | jgraham: http://pastebin.ca/1622716 |
| 21:26 | <Hixie> | http://www.w3.org/mid/49142F02149340458FDD20841AD0AD56299545A7⊙Twwnmc |
| 21:27 | <Hixie> | i see they are still effectively fracturing the web, presumably despite their best intentions |
| 21:53 | <scherkus> | anyone care to help me understand "awaiting for a stable state?" |
| 21:57 | <Hixie> | scherkus: context? |
| 21:58 | <roc> | I still think these modes a colossal burden that will eventually crush them, without affecting the rest of us much |
| 21:59 | <scherkus> | Hixie: media selection algorithm |
| 21:59 | <scherkus> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/#concept-media-load-algorithm |
| 22:00 | <Hixie> | ah if you mean "awaiting a stable state", that's a term defined in the event loop section |
| 22:00 | <Hixie> | click the link that says "await a stable state" |
| 22:00 | <Hixie> | for the definition |
| 22:01 | <scherkus> | so run the asynchronous algorithm's synchronous section? |
| 22:01 | <Hixie> | more or less, yes |
| 22:01 | <Hixie> | it means waiting for the event loop to be done running its current task |
| 22:01 | <scherkus> | right |
| 22:02 | <scherkus> | ok that makes more sense now |
| 22:02 | <scherkus> | but if that was already taken care of |
| 22:02 | <scherkus> | then essentially I'm already in a stable state |
| 22:25 | <Dashiva> | I guess this fear that microdata will steamroll RDFa if it isn't removed from the spec is a pretty good stamp of quality |
| 22:26 | <jgraham> | gsnedders: No need for the tre lines of += at the end just use a single formtting string like "%s %s %s)%(quote_char, doctype["ystemId"], quote_char) |
| 22:27 | <othermaciej> | I think whether microdata steamrolls RDFa (or vice versa) will not bear much relation to whether it is in the spec |
| 22:27 | <Dashiva> | othermaciej: That's also a reasonable position, but in that case we're wasting a lot of cycles discussing it |
| 22:28 | <othermaciej> | Dashiva: my feeling is this - failing to resolve the issue (even if it is largely political) will cause the HTML WG even more pain and hassle down the road |
| 22:28 | <othermaciej> | maybe I am being selfish hear, since I will have to bear the brunt of much of the future hassle |
| 22:28 | <othermaciej> | s/hear/here/ |
| 22:29 | <Dashiva> | No, that's right. I don't think agreement to just drop the issue will ever appear. |
| 22:30 | <Dashiva> | But it might say something about people's motivations |
| 22:31 | <Dashiva> | Hang in there, by the way. We need all the chairing we can get ;) |
| 22:31 | <gsnedders> | jgraham: That's ugly too |
| 22:34 | <Prest0> | is html5 finalized? |
| 22:35 | <daedb> | no |
| 22:36 | <Prest0> | is it anywhere close? |
| 22:37 | <TabAtkins> | Prest0: What do you mean by 'finalized'? |
| 22:38 | <Prest0> | is the specifications finished and implemented |
| 22:38 | <TabAtkins> | (daedb was right for any reasonable definition, but your second question needs clarification.) |
| 22:38 | <TabAtkins> | How much implementation is required, and by how many people? |
| 22:38 | <TabAtkins> | s/people/browsers/ |
| 22:39 | <Prest0> | hah, i know mozilla is saying how great it is and that they are adopting it and microsoft recently said that they will implement it |
| 22:39 | <TabAtkins> | Yes, everyone's committed to implementing it. But I need to know what your criteria is before I can say how far we are from meeting it. |
| 22:40 | <Prest0> | are all features that the html5 spec defines implemented in atleast 1 browser |
| 22:40 | <TabAtkins> | Frex, if your criteria is "100% implementation by at least two implementors" (the requirements for w3c Recs), then the best guess is the old 2022 date. (Note, though, that HTML4 isn't 'finalized' by this criteria. |
| 22:40 | <TabAtkins> | No, not all of them. |
| 22:41 | <Prest0> | what is missing in firefox? |
| 22:41 | <Prest0> | (who i assume is farthest along atm) |
| 22:41 | <TabAtkins> | The spec should make that relatively clear per-feature with the implementation statuses. |
| 22:41 | <TabAtkins> | (And actually, webkit may be 'farthest along', though that's probably a meaningless statement.) |
| 22:41 | <Prest0> | where are the statuses? |
| 22:42 | <TabAtkins> | When you're looking at the spec on whatwg.org, next to each feature, along the left side, is a colored box. It'll have pictures of the browsers that support that feature. |
| 22:42 | <Prest0> | does ie8 work with the new tag elements? |
| 22:42 | <TabAtkins> | If you hover over one of them, it'll give more details on the level of support. |
| 22:42 | <Prest0> | ah cool |
| 22:42 | <daedb> | New elements in IE8 needs a script. |
| 22:43 | <TabAtkins> | IE8 has the same level of support as IE7 and below - it still treats them as unknown elements, and parses them badly unless you do the createElement() hack. |
| 22:44 | <Prest0> | is 2022 a real date laid out in some roadmap or just a hyperbole for a long time from now |
| 22:45 | <TabAtkins> | It was a best-guess made by Ian. |
| 22:46 | <Prest0> | cool, thanks for all the info |
| 22:46 | <TabAtkins> | Like I said, though, HTML4 isn't finalized by that criteria yet, and never will be. |
| 22:46 | <TabAtkins> | Neither is CSS1. |
| 22:46 | <TabAtkins> | Both of which are over a decade old. |
| 22:47 | <Prest0> | haha, when will html be as useable as html4 do you think? |
| 22:49 | <TabAtkins> | Hmm, depends somewhat on what parts you're talking about, but I'd say give it a few years. If we can get legacy IEs to die at an appropriate pace we'll be in business - they'll be the albatross around our neck for a long time. |
| 22:49 | <TabAtkins> | You can start using some of HTML5 right now, of course. After all, quite a bit of it was reverse-engineered *from* IE. |
| 22:50 | Philip` | really doesn't understand what Martin McEvoy means about landing planes |
| 22:50 | <TabAtkins> | Philip`, I'm actually having a hard time understanding him at all. I've asked him to break up his sentences a bit more, as it's very hard to parse sentences that span an entire paragraph. |
| 22:53 | <Philip`> | I can understand his paragraphs fine, by inferring sentence breaks |
| 22:53 | <Philip`> | I think I just don't understand his underlying points or perspective |
| 22:54 | <mikekelly> | hi fans |
| 22:54 | <mikekelly> | :P |
| 22:55 | <mikekelly> | Hixie: guess what I've been discussing again.. :D |
| 22:56 | <Philip`> | mikekelly: Does it begin with "con" and end with "tent negotiation"? |
| 22:58 | <daedb> | Philip`: How do you negotiate with tents anyway? :) |
| 22:59 | <mikekelly> | it *might* do |
| 22:59 | <mikekelly> | yeah it does |
| 22:59 | <TabAtkins> | daedb: Have you ever been to a con? Tents are srs bznss. |
| 22:59 | <mikekelly> | I need help |
| 22:59 | <mikekelly> | but first, I have to help you sort out this poopy hyperlink problem you have |
| 23:00 | <mikekelly> | I keep giving up on you and then thinking about better ways to explain it and coming back |
| 23:00 | <daedb> | TabAtkins: I have, but not recently... it was before the tents took over. |
| 23:01 | <Philip`> | daedb: It's basically the same as negotiating with terrorists, only ... uh, tentier |
| 23:02 | <TabAtkins> | We have a hyperlink problem? I only hyperlink with friends! It's social hyperlinking! |
| 23:03 | <mikekelly> | don't be ridiculous being social is a centralised process |
| 23:03 | <mikekelly> | you need accurate ratings for this shit |
| 23:03 | <mikekelly> | it's serious stuff. |
| 23:04 | <mikekelly> | so anyway I think I've found some hint of support for what I was going on about before |
| 23:04 | <mikekelly> | http://tech.groups.yahoo.com/group/rest-discuss/message/13858 - read on from there, if you dare! |
| 23:05 | <Philip`> | s/dare/care/ |
| 23:06 | <mikekelly> | I was going to put that but it's just asking for it |
| 23:07 | <mikekelly> | smarty pants. |
| 23:07 | <mikekelly> | I would seriously like someone to take a read of that and give the official line |
| 23:08 | <Philip`> | The WHATWG doesn't do "official" |
| 23:08 | <mikekelly> | on the mailing list or on here I don't care I just want to know where we stand because I've had nothing further back on the bug since it was insta-resolved by Ian |
| 23:08 | <mikekelly> | well I've had something back since then but I have un-addressed replies |
| 23:09 | <mikekelly> | if necessary I'd like to escalate this to the chair |
| 23:10 | <hober> | IIRC the WHATWG doesn't have a chair |
| 23:10 | <mikekelly> | Ian suggested that as the next course of action |
| 23:10 | <mikekelly> | oh wait. |
| 23:10 | <Philip`> | We all have to stand up |
| 23:10 | <hober> | there are people in the WHATWG charter who can override Ian, but that's never happened. |
| 23:10 | <TabAtkins> | HTMLWG, of course, has a chair. It has three of them! |
| 23:10 | <TabAtkins> | We all share. |
| 23:10 | <Philip`> | If he said that in the W3C Bugzilla, it was probably in the context of the HTML WG |
| 23:11 | <mikekelly> | joking aside.. what is actually the next steps here |
| 23:12 | <TabAtkins> | (Officially I have no position on this issue. I'm not certain if it solves a worthwhile problem, but if it does, then I'm not opposed to the proposed solution.) |
| 23:12 | <TabAtkins> | (Officially I have no more authority than you, though.) |
| 23:12 | <TabAtkins> | Well, was it in the w3c bugtracker? |
| 23:12 | <TabAtkins> | We have a whole Process now. It's official. |
| 23:12 | <Philip`> | mikekelly: The recently-proposed (not yet accepted, but generally uncontroversial) HTML WG process is at http://dev.w3.org/html5/decision-policy/decision-policy.html |
| 23:13 | <mikekelly> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7697 |
| 23:14 | <mikekelly> | for guys looking to stick to HTTP and be strict on resource identification |
| 23:14 | <mikekelly> | html is a serious limitation |
| 23:15 | <mikekelly> | The XInclude spec [1] defines the accept and accept-language attributes for links: http://www.w3.org/TR/xinclude/#include_element |
| 23:15 | <TabAtkins> | All right, so by the flow-chart you can either take path 5c or 5d. Be careful, though, as you may be eaten by a Grue. |
| 23:16 | <TabAtkins> | Without further information (which it doens't look like exists from the bug), 5c is probably not the way to go. So 5d, escalate to Issue, would probably be the correct path. |
| 23:17 | <mikekelly> | lovely warm robotic feeling to this process |
| 23:17 | <TabAtkins> | Most robots are warm due to their steam engines. It is indeed lovely. |
| 23:17 | <mikekelly> | you the man. |
| 23:20 | Philip` | has fun writing a fourth SpiderMonkey<->C++ bridge in his game |
| 23:20 | <TabAtkins> | What game? |
| 23:21 | <Philip`> | Just some unfinished RTS game |
| 23:22 | <mikekelly> | serious project or just something to impress the ladies? |
| 23:22 | <TabAtkins> | ?_? Team Foundation Server is marking the wrong lines as changed in this diff. How strange. |
| 23:23 | <scherkus> | quick clarification... when the spec says "when the media element has no src attribute" does that imply that it was never set, or that it was set to something like "" (empty string) |
| 23:23 | <Philip`> | Supposedly serious, and I doubt it will have the latter effect |
| 23:24 | <Hixie> | scherkus: it implies that the element at the time of the check does not have a src attribute at all |
| 23:24 | <Hixie> | scherkus: (the attribute could have been set and then removed, and it would match this) |
| 23:24 | <Hixie> | scherkus: (but setting it to "" counts as it being present) |
| 23:24 | <scherkus> | Hixie: ok, so then we should expect an error because loading "" is not a valid URL |
| 23:25 | <Hixie> | "" is a valid URL |
| 23:25 | <Hixie> | it's a relative URL that resolves to the same thing as the base URL |
| 23:25 | <Hixie> | (typically the web page, but not necessarily) |
| 23:25 | <scherkus> | Hixie: er.. right but to the underlying media engine it will probably throw an error heh |
| 23:26 | <scherkus> | Hixie: it looks like webkit gets stuck in NETWORK_LOADING because the "" case slips through the cracks |
| 23:27 | <Hixie> | scherkus: typically it should end up trying to use an HTML page as a video, and that would fail, yeah |
| 23:27 | <Hixie> | scherkus: but the base URL could be set to a video |
| 23:27 | <Hixie> | scherkus: or the server could return an HTML file the first time and a video the second |
| 23:27 | <Hixie> | i've written similar test cases for CSS |
| 23:28 | <mikekelly> | hi Ian |
| 23:29 | <scherkus> | Hixie: yeah that makes sense.. it says right there that the url gets resolved and loaded.. don't see a reason why "" would be excepted |
| 23:29 | <scherkus> | thanks! I'll plug away |
| 23:32 | <TabAtkins> | I wonder if there's any way to make a polyglot video/html page? Do any of the video formats accept arbitrary data in a header or something? |
| 23:34 | <Philip`> | TabAtkins: It's easy when the HTML doesn't have to be valid |
| 23:36 | <TabAtkins> | Yeah, that'd probably be the idea. |
| 23:44 | <nessy> | TabAtkins: you can throw arbitrary data into Ogg headers - either in skeleton (for the complete file) or in vorbiscomment (per track) |
| 23:52 | <mikekelly> | isn't that what chunked encoding is for? |