00:11 | <Hixie> | ok we're gonna synchronously fire an 'abort' event while load() is running, followed by an 'emptied' event. |
00:11 | <Hixie> | the next questios whether to fire the 'begin' event before or after the method returns |
00:11 | <Hixie> | and whether to set the state to LOADING before or after the method returns |
00:11 | <Hixie> | i'm pretty sure we want to set LOADING before. |
00:12 | <Hixie> | but if we fire 'begin' afterwards, that would mean there's a period of time where it's LOADING and there is script running even though the 'begin' event hasn't fired yet |
00:12 | <Hixie> | i suppose now that we have 'abort' firing synchronously we can do the same with 'bugin' |
00:12 | <Hixie> | 'begin' even |
00:28 | <Hixie> | hm, we're gonna have to change the html parsing spec to not drop <option> elements to support web forms 2 <datalist> |
04:52 | <zcorpan> | morning |
04:53 | <Lachy> | hey zcorpan |
04:53 | <Lachy> | how did your interview at Opera go? |
05:02 | <zcorpan_> | Lachy: it went well (see logs) |
05:02 | <Lachy> | in this channel or #html-wg? |
05:02 | <Lachy> | and on what date? |
05:03 | othermaciej | wonders if he could get a req approved to hire a standards expert so he can order others to flame on mailing lists and go to useless meetings instead of doing it himself |
05:04 | <zcorpan__> | 18:19 20070403 #whatwg |
05:08 | <Lachy> | where is Jönköping? |
05:08 | Lachy | looks it up in google maps... |
05:09 | <Lachy> | ah, Sweeden |
05:11 | <zcorpan__> | content authors will continue to use flash until <video> works with one codec across the browsers the author cares about |
05:12 | <zcorpan__> | then they might reconsider |
05:16 | <Lachy> | and they will only switch from flash to <video> if there are clear benefits to do so |
05:17 | <Hixie> | othermaciej: if you do do that, make sure it's someone who actually knows what they're talking about |
05:17 | <Hixie> | othermaciej: a lot of companies will hire ivory tower people to do that and that's how you end up in the mess we have now :-) |
05:18 | <othermaciej> | Hixie: I would only hire someone for such a post whose standards-related work I was personally familiar with, most likely |
05:18 | <Hixie> | that works |
05:19 | <othermaciej> | I think I know which subset of those reflects a good set of web standards values |
05:20 | <KevinMarks> | do what? |
05:21 | <othermaciej> | KevinMarks: that's a convoluted way of saying "people who are not idiots and whose opinions about web stuff are reasonably similar to my own" |
05:23 | <zcorpan> | what will the hired someone do? |
05:24 | <othermaciej> | participate in standards groups, help develop standards, help write specs for apple proposed standard features, make standards-driven test cases for both official standard body use and for webkit regression testing use |
05:24 | <othermaciej> | but I'm not yet sure if I need a special person to do that or can get people I work with to do more of that kind of stuff |
05:25 | <Lachy> | do you have anyone in mind who you'd like to hire. if you could? |
05:27 | <othermaciej> | I have a likely short list in mind, but probably not worth discussing further until the position is less hypothetical |
05:27 | <Lachy> | fair enough |
05:27 | <KevinMarks> | would that include iTunes baroque RSS support or is this a pure webkit position? |
05:28 | <othermaciej> | mainly web standards that are relevant to Safari/WebKit though I'd hope there could be internal advocacy to other teams at Apple when appropriate |
05:28 | <othermaciej> | (lord knows I don't have the time for such things) |
05:59 | <karlUshi> | othermaciej: I think it is a mistake to hire someone for a standard group as it disconnects the person from the real work in the team. It would work only if the person was really working with all engineers on a daily basis. |
06:00 | <othermaciej> | karlUshi: I would expect such a person to work actively with the team, though probably more on testing than implementation |
06:00 | <karlUshi> | though someone specialist of Web stuff advocating to all teams developing things related to html inside the company could indeed be a good thing |
06:00 | <karlUshi> | othermaciej: yes testing seems a good option |
06:01 | <karlUshi> | for spec writing we lack often of good technical writers too, or at least technical writers for reviewing the spec. |
06:02 | <karlUshi> | hmmm thinking of it. Apple might have in-house technical writers who could read stuff |
06:03 | <othermaciej> | we have tech writers but I think at best they could help with copyediting |
06:22 | <zcorpan> | with firefox 3, i can finally start to use display:inline-block. :) floats can be such a pita when you really just want inline-block |
08:07 | <Hixie> | othermaciej: when talking about the CAN_SHOW_this or that states, complete this sentence: "Media elements have a state which describes..." |
08:08 | <othermaciej> | "... their current degree of presentability" |
08:08 | <othermaciej> | "... their current degree of presentability at the current time position" |
08:08 | <Hixie> | that works |
08:08 | <Hixie> | thanks |
10:36 | <Hixie> | this <video> patch to introduce the new state systems is gonna be a whopper. |
10:36 | <Hixie> | it's over 1500 lines already |
12:29 | <hsivonen> | It'll be interesting to see what Nokia ships when Opera is ready to offer them Theora support as part of the engine |
12:31 | <MikeSmith> | hsivonen - didn't (somebody) say that there was no way that Nokia would ship Theora? |
12:33 | <hsivonen> | MikeSmith: timeless said on the list that they wouldn't. And the manager of the whole Maemo operation earlier said that they wouldn't ship Vorbis without their own people vetting it first (without indication of whether any vetting is actually taking place). |
12:37 | <hsivonen> | taking out features from Presto due no an OEM legal policy would be uncool, though |
12:38 | <hsivonen> | s/no/to/ |
13:04 | <MikeSmith> | hsivonen - yeah, certainly would not be the best thing for end users |
13:49 | Dorward | hears a rumour that Hixie is pushing for clients to be allowed to treat text/plain documents as HTML and points out that when Safari did that to http://www.hixie.ch/advocacy/xhtml it became rather difficult to read. |
13:50 | <Dashiva> | Rumors aren't always that reliable |
13:50 | <Dorward> | Dashiva: No, which is why I <em>ed that it was a rumour rather then acting as though it was fact. |
13:58 | <zcorpan> | now we need another google project: a blog using genchi |
13:59 | <zcorpan> | should be straight-forward to migrate from WP or other popular blogs to that hypothetical blog |
14:00 | <zcorpan> | and it should integrate with hsivonens validator |
14:18 | <Dashiva> | "The src content attribute on media elements gives the address of the video to show." |
14:19 | <Dashiva> | Hixie: Maybe that should say media instead of video? |
16:56 | <annevk> | hello |
17:07 | <zcorpan> | hello annevk |
17:08 | annevk | though that HTMLImageElement.complete was some new feature but apparently browsers already support it in incompatible ways |
17:09 | <annevk> | I suppose "in incompatible ways" goes without saying... |
17:12 | <Philip`> | I've used that in Firefox and Opera with no problems (to poll for image loading, since I didn't want to use events), though my code was gratuitously incompatible with IE anyway so I have no idea how it handles complete |
17:13 | <annevk> | Philip`, what did you use it for? |
17:13 | <Philip`> | But "The DOM attribute complete must return true if the user agent has downloaded the image specified in the src attribute, and it is a valid image." doesn't seem to agree with what I found - I'm fairly sure I had complete==true once the image had failed to load (e.g. with a 404 error) |
17:13 | <Philip`> | (so I tested width!=0 to see if it had actually loaded successfully, and replaced it with an error image otherwise) |
17:14 | annevk | used "javascript:alert((new Image()).complete)" as testcase |
17:15 | <Philip`> | That was just in a canvas game, which loaded images while running and only wanted to check for updated status between frames |
17:19 | annevk | will make some testcases later to test interop a bit better |
17:19 | annevk | is going to fetch a Wii now! |
17:20 | <Philip`> | Hmm, I can't work out what I was doing that made it look like it worked, or whether I was just imagining the whole thing... |
17:22 | <Philip`> | Oh wait, that's because I'm trying .completed instead of .complete, hence it always returning undefined... |
17:24 | <Philip`> | data:text/html,<script>var i=new Image(); i.src="http://microsoft.com/404"; alert(i.complete); setTimeout(function(){alert(i.complete)}, 1000);</script> |
17:24 | <Philip`> | That does what I expected - False at first, then True after it's got the error response |
17:24 | <Philip`> | but only in FF/Opera - IE returns False/False |
17:45 | <annevk> | IE makes more sense imo |
17:48 | gavin_ | quotes annevk out of context |
17:48 | <gavin_> | I can see it on Digg now |
17:48 | <annevk> | :p |
17:53 | <Philip`> | IE isn't as useful since it only allows the polling-equivalent of onload and you can't poll for the same conditions as onerror, whereas FF/O sort of let you tell the difference between complete-successful and complete-error |
17:53 | <Philip`> | but IE does make more sense for something called "complete" |
17:54 | <annevk> | afaict the attribute just reflects whether the load event has been dispatched on the element or not |
17:55 | <annevk> | i suppose what FF/O is let it reflect whether load or error has been dispatched |
17:55 | <annevk> | (but that may be what you just said, I'm a bit dense) |
17:57 | <Philip`> | That was what I was thinking (and what seems to happen when I test it), though I'm not sure if what I actually said made sense :-) |
18:01 | <annevk> | That doesn't seem to be true either |
18:02 | <annevk> | alerting complete in a load event handler returns false in IE |
18:03 | <annevk> | Philip`, it's a security risk... consider an image from an intranet |
18:05 | <annevk> | .complete does return true after the load event of the window object is dispatched, but not before... |
18:05 | annevk | wonders if that can be considered a bug in IE |
18:06 | <Philip`> | For data URLs? I was thinking that if you are able to call canvas.toDataURL, you are the same person who was calling canvas.drawImage, so you had the Image, so you could read image.src and get the image data out. But I don't know how much cross-domain scripting is allowed, and whether one of those assumptions is wrong |
18:09 | <annevk> | Philip`, the only way to get the image data is through <canvas> |
18:09 | <annevk> | Philip`, hence the restriction |
18:10 | <annevk> | (the security model of the web is rather odd, but we have to deal with it :)) |
18:11 | <Philip`> | But when the image is loaded from a data: URL (e.g. because it came from another call to canvas.toDataURL), you can read .src and get the image data without using the canvas at all |
18:12 | <Philip`> | like by writing a PNG decoder in JavaScript, which I guess is a little painful but theoretically possible |
18:12 | <annevk> | I'm not up to speed with data: URIs and security, sorry |
18:14 | <annevk> | One thing that is problematic with data: URIs if I remember correctly is when they are the result of a redirect |
18:17 | <Philip`> | Ah, sounds like that kind of thing makes it awkward |
18:24 | <annevk> | http://tc.labs.opera.com/html/img/ has four tests which show that no browser implements the spec |
18:29 | <Philip`> | And none misimplement it in the same way |
18:29 | <Philip`> | Test: 1 2 3 4 |
18:29 | <Philip`> | Firefox: F P P F |
18:29 | <Philip`> | Opera: F P P DNR |
18:29 | <Philip`> | IE: P F F P |
18:29 | <Philip`> | Safari: F F F DNR |
18:34 | <zcorpan> | another <figure> with <credit>: http://www.tellusgame.com/Tellusfilm/2.%20Finished/artikelsidan.html |
18:36 | <zcorpan> | i've noticed that whatever html5 feature i use (usually type=email &c), as soon as i pass the code to someone else it disappears. probably their editors or tools remove them or complain about them |
18:37 | <zcorpan> | or they are dicks and want to pass validator.w3.org |
18:45 | <zcorpan> | http://www.tellusgame.com/Tellusfilm/2.%20Finished/kronikorsidan.html has only <credit> and no caption for the figures |
18:50 | <zcorpan> | firefox seems to be buggy about display:table-cell. sometimes they get rendered on their own line. on reload it renders correctly |
18:50 | zcorpan | will try to reproduce with a simpler test case |
19:04 | <annevk> | Microsoft just joined the HTML WG |
19:04 | <annevk> | With Chris Wilson as their sole participant |
19:07 | <annevk> | if Martin Atkins is around, my apologies... |
19:11 | <Dashiva> | How so? |
19:11 | <annevk> | for asking he question he apparently already addressed |
19:12 | <annevk> | s/he question/a question/ |
19:46 | <zcorpan> | hsivonen: would it be possible to generate a typesetted pdf of the spec dynamically? would be nice to offer a printable version of the latest spec without having people to typeset it manually |
20:06 | <hsivonen> | zcorpan: yes, it would be reasonable. however, I think I'd overstep my Prince license if I did that |
20:06 | <hsivonen> | zcorpan: but with a Server license, no technical problem |
20:06 | <annevk> | I suppose we might be able to get one... |
20:09 | <hsivonen> | zcorpan: I guess the best way to do it would be installing Prince (under a server license) on Dreamhost and running it in an SVN post-commit hook each time Hixie commits a new version |
20:09 | <hsivonen> | it should probably be run twice: A4 and Letter |
20:13 | <hsivonen> | hmm. Perhaps if Hixie is the licensee and invokes Prince as part of his commit script, a Single-User license with Hixie as the licensee would work |
20:15 | <annevk> | There's quite a few Prince people on the WHATWG list |
20:18 | <hsivonen> | annevk: I know. More the reason to comply. :-) but OTOH, more chance that the Prince people might help with such a setup |
20:18 | annevk | points molly to http://simon.html5.org/test/ie7b2-bugs/ |
20:22 | zcorpan | should probably mark the ones already fixed as obsolete |
20:23 | <annevk> | you could add a readm.txt mentioning all the fixed tests |
20:23 | <annevk> | readme* |
20:24 | <zcorpan> | you know off-hand which they are? |
20:24 | <annevk> | nope |
20:25 | <zcorpan> | ok |
21:43 | <annevk> | http://twitter.com/Hixie/statuses/14588161 |
21:43 | <annevk> | seems Hixie adopted twitter |
21:43 | <othermaciej> | ! |
21:44 | <hober> | yay! |
21:46 | <othermaciej> | haha, I know what group that is |
21:47 | <Hixie> | blame tantek |
21:47 | <Hixie> | for me using twitter |
21:47 | <Hixie> | i wish it worked though |
21:47 | <othermaciej> | wow, that's a whole lotta twittering |
21:47 | <Hixie> | the jabber server never sends me updates |
21:48 | Hixie | uses it as an IM away message |
21:48 | <annevk> | oh yeah, I just picked a funny line |
21:48 | <tantek> | Hixie, check your prefs and make sure you set (*) IM |
21:48 | <Hixie> | i have |
21:48 | <Hixie> | and i've said 'on' |
21:48 | <tantek> | and then i believe you have to appear "online" |
21:48 | <tantek> | rather than "away" |
21:48 | <Hixie> | i do |
21:48 | <tantek> | otherwise i think it stops sending them to your jabber |
21:48 | <tantek> | er, im |
21:48 | <tantek> | odd |
21:49 | <Hixie> | i'm present, logged in, enabled it, confirmed it with the code, said 'on', the works |
21:49 | <Hixie> | never gotten it to send any of my friends' messages to me |
21:49 | <Dashiva> | The twitter server seems slow like the css 2.1 specification process |
21:50 | Dashiva | notes that Hixie himself only sends lggwg moves during like 1/4 of the day |
21:51 | <Hixie> | more like 3/4 |
21:51 | <Hixie> | but sure |
21:51 | <othermaciej> | if twitter starts containing useful information, I might have to sign up :-( |
21:52 | annevk | was wondering about the same thing |
21:52 | <Hixie> | twitter, as far as i've experienced, is a write-only medium |
21:52 | <Hixie> | note that my blog shows my status and updates it in real time if you leave the page open |
21:53 | <hsivonen> | twitter on ADSL is slower than Flickr on GPRS |
21:56 | <tantek> | btw, some folks hangout sometimes in #twitter |
21:57 | <tantek> | and at least you can twitter about any problems you have on twitter |
21:57 | <Dashiva> | We could make a twitter clone that selects random lines from IRC instead :) |
21:58 | <annevk> | krijnh, could modify his bot so we could do "twitter: blah" and it would appear in some #whatwg twitter |
21:58 | <Dashiva> | twitter: Hi mom |
21:58 | <Hixie> | tantek: i've done so several times :-) |
21:59 | <Hixie> | tantek: i really have no idea why it doesn't work |
22:01 | <tantek> | How strange - I thought I had added you and for some reason when I went to your profile I had not. |
22:01 | <othermaciej> | the twitter web site seems to be pretty slow right now |
22:01 | <tantek> | re-adding twitter.com/hixie |
22:01 | <tantek> | ah there are your bug reports |
22:01 | <tantek> | ok, let's try this... |
22:02 | <hsivonen> | aaagh. Atom abuse by twitter: double escaped titles |
22:03 | <hsivonen> | getting rid of this problem is why Atom exists |
22:04 | <Dashiva> | Making it easier to do it right just means more energy left for doing it wrong! |
22:04 | <annevk> | i suppose that shows that inventing something new doesn't solve problems |
22:08 | <tantek> | hsivonen - I use XHTML titles and very few Atom consumers decode them - instead I see literal: "<div> Tantek's Updates</div>" as the title |
22:09 | <tantek> | e.g. http://blogsearch.google.com/blogsearch?q=link:tantek.com&scoring=d |
22:09 | <annevk> | nowadays i think that Atom might have been a mistake |
22:10 | <tantek> | Of course Technorati's Atom parsing is compliant (as one of the earlier consumers: http://www.intertwingly.net/wiki/pie/KnownAtomConsumers ) |
22:10 | <KevinMarks> | the problem is the pain people went through for RSS lingers in their atom parsers |
22:10 | <zcorpan> | is http://simon.html5.org/test/ie7b2-bugs/037.html valid or not? |
22:10 | <tantek> | annevk, as a publisher, I'm very happy about Atom being there - semantics are much more well defined |
22:11 | <annevk> | tantek, we could have fixed RSS to make semantics well defined |
22:11 | <KevinMarks> | and as a parser, it is way better |
22:11 | <annevk> | zcorpan, it's valid per HTML5, yes |
22:11 | <othermaciej> | it would have been better to fix RSS |
22:11 | <tantek> | and rel="enclosure" made it trivial to mark media items that I had already been linking to as podcast items |
22:11 | <zcorpan> | annevk: ok |
22:11 | <KevinMarks> | that was made impossible |
22:11 | <KevinMarks> | really |
22:11 | <tantek> | as opposed to dealing with yet another random new element |
22:11 | <hober> | I don't think fixing RSS was, politically, an option |
22:11 | <annevk> | in due course someone still has to fix RSS and Atom |
22:11 | <KevinMarks> | Atom is fixed |
22:12 | <annevk> | the Atom specification doesn't say what consumers should do with invalid Atom |
22:12 | <tantek> | annevk - no, people tried fixing RSS to make its semantics well defined and failed. That's why Atom happened. See: Sam Ruby, Tim Bray. |
22:12 | <KevinMarks> | the feed validaotr makes invalid atom very clear |
22:12 | <tantek> | Atom is much more easily "fixed" in that regard (interoperable error handling) than RSS. |
22:13 | <annevk> | the HTML WG tried to fix HTML at some point to and then went on with XHTML2 because it was considered too hard |
22:13 | <KevinMarks> | with RSS the error message are more like 'this is a matter of debate' |
22:13 | <annevk> | RSS should be "trivial" compared to HTML |
22:13 | <tantek> | annevk, no that's not the reason |
22:13 | <tantek> | there was political motivation/pressure to do a "pure XML" version of HTML |
22:13 | <KevinMarks> | which became RSS 1.0, the RDF flavour |
22:13 | <tantek> | that was greater than the pressure to "fix" HTML |
22:13 | <othermaciej> | Atom does seem like an XHTML2-style solution |
22:13 | <annevk> | ok, maybe the former XForms WG then |
22:13 | <tantek> | some folks had the delusion that "pure XML" = "fix" |
22:14 | <KevinMarks> | RSS 1.0 was the xhtml2-like solution |
22:14 | <annevk> | probably the XForms people, yes |
22:14 | <hober> | KevinMarks: exactly |
22:14 | <tantek> | KevinMarks FTW |
22:14 | <annevk> | Atom is yet another one |
22:14 | <KevinMarks> | no |
22:14 | <tantek> | Atom doesn't have that much reinvention. |
22:14 | <KevinMarks> | I suppose hAtom is the HTML solution... |
22:15 | <annevk> | in two flavors, 0.3 and 1.0 |
22:15 | <hsivonen> | tantek: I use XHTML titles as well. No complaints. However, many Atom consumers don't get namespace-prefixed XHTML right. |
22:15 | <annevk> | tantek, it does, it has all the same features under different element names |
22:15 | <tantek> | hsivonen, I use @xmlns rather than namespace-prefixed tags |
22:15 | <KevinMarks> | as opposed to the 9 or 12 flavours of RSS |
22:15 | <tantek> | annevk, not quite - it has more and more precise semantics |
22:15 | <tantek> | (atom vs. rss) |
22:16 | <annevk> | KevinMarks, well, you have to support all those flavors already |
22:16 | <othermaciej> | fortunately Atom and RSS are both much simpler than HTML |
22:16 | <KevinMarks> | it specifies which elements can contain HTML |
22:16 | <annevk> | KevinMarks, so better fix those than introduce even more |
22:16 | <hsivonen> | tantek: me too for the feed that I actually intend to be read. however, to point out brokenness I have implemented a non-canonical feed elsewhere |
22:16 | <othermaciej> | so an incompatible break is merely inordinately expensive as opposed to impossible |
22:16 | <hober> | Fortunately, Mark Pilgrim et al. already did all the heavy lifting, by writing the UFP :) |
22:16 | tantek | leaves it to KevinMarks to provide the rest of the history of Atom lesson. |
22:17 | annevk | was part of the Atom WG |
22:17 | KevinMarks | was too |
22:17 | annevk | doesn't need history lessons about it |
22:17 | <hsivonen> | Atom wasn't like XHTML 2.0. HTML didn't have a Winer. |
22:17 | <KevinMarks> | so how would you propose fixing RSS? |
22:17 | hsivonen | was also part of the Atom WG |
22:17 | <othermaciej> | making a whatwg style community breakaway spec for RSS might have, in retrospect, been better |
22:18 | <tantek> | I thought that was what was tried, by Cadenhead |
22:18 | <hober> | othermaciej: in some sense, that's what the RSS AB is |
22:18 | <hober> | tantek: right |
22:18 | <tantek> | with the RSS committee or WTF it was called |
22:18 | <annevk> | much the same way HTML has been fixed |
22:18 | <hober> | the rss advisory board |
22:18 | <tantek> | but that blew up in a bunch of blog drama AFAIK |
22:18 | <tantek> | yeah that thing |
22:18 | <annevk> | I think that was a pretty silly effort |
22:18 | <annevk> | not much community involvement at all and it focused on paragraph level changes as opposed to actually digging up all the issues etc. |
22:20 | <othermaciej> | anyway, it's true that staging a hostile takeover of a broken spec is harder than making a new one |
22:20 | zcorpan | added some notes to http://simon.html5.org/test/ie7b2-bugs/ |
22:20 | <annevk> | problem is that the new one doesn't define much error handling either |
22:20 | <hober> | annevk: I'd say that that's an underlying problem with xml |
22:21 | <hober> | seems to me the html5lib liberalxmlparser is showing the way in that case |
22:21 | <annevk> | hober, I don't mean namespace-well-formedness error handling |
22:21 | <hober> | I know what you mean |
22:22 | <annevk> | what to do with a feed <feed xmlns="atomns"></feed> |
22:22 | <tantek> | othermaciej - good point |
22:22 | <tantek> | however, if any group *could* do it, i think whatwg could |
22:22 | <tantek> | and certainly would get a lot of, ahem, press for it |
22:22 | <annevk> | we already defined sniffing for feeds |
22:22 | <tantek> | because you can almost guarantee a fairly high level of blog drama |
22:22 | <annevk> | well, Hixie did |
22:23 | <tantek> | is there an RSS 2.1 spec? |
22:23 | <othermaciej> | I think the takeover of html is keeping everyone sufficiently busy |
22:23 | <hober> | othermaciej++ |
22:23 | <tantek> | agreed. fixing HTML is much more important than fixing RSS |
22:23 | <annevk> | hober, I plan to remove namespace-well-formed from XML btw |
22:23 | <Philip`> | Maybe work on RSS5 can be slotted between HTML5 and XML5 |
22:23 | <kingryan> | why don't we just obsolete RSS? |
22:24 | <hober> | kingryan: RFC4287 already did :) |
22:24 | kingryan | points at http://microformats.org/wiki/hatom |
22:24 | <annevk> | kingryan, obsolete in what sense? |
22:24 | <hsivonen> | I think an RSS5 would be destructive to the atmosphere of the WHATWG list |
22:24 | <annevk> | rss-whatwg |
22:24 | <tantek> | especially since "S" and "5" look too similar in many fonts |
22:24 | <Dashiva> | It would be much more effective to aim for legislation making RSS illegal |
22:25 | <hsivonen> | people are nicer on the WHATWG list than on the AtomPub list |
22:25 | <othermaciej> | things that are more important to fix than RSS include: |
22:25 | <tantek> | when RSS is outlawed, only outlaws will (be in a) syndicate ? |
22:25 | <kingryan> | annevk: create something more useful and easier to us |
22:25 | <kingryan> | use* |
22:25 | <othermaciej> | DOM Core, CSS, SVG |
22:25 | <hsivonen> | syndication in general and RSS in particular make people act in non-nice ways |
22:25 | <othermaciej> | MathML is probably less important to fix than RSS |
22:25 | <tantek> | SVG? that needs something much more like Atomization treatment |
22:26 | <annevk> | VML! |
22:27 | <tantek> | annevk, no no no, you really want VRML. |
22:27 | <zcorpan> | TIME |
22:27 | <tantek> | keeps on ticking |
22:27 | <zcorpan> | or, SMIL |
22:28 | <annevk> | othermaciej, HTTP |
22:28 | <annevk> | XML |
22:28 | <annevk> | video codecs :) |
22:28 | <hsivonen> | WS-*5 |
22:28 | <annevk> | heh |
22:29 | <zcorpan> | RDF5 |
22:29 | <othermaciej> | HTTP spec does need fixing |
22:29 | <othermaciej> | I don't know what is wrong with XML offhand |
22:29 | annevk | wants graceful error handling |
22:29 | <othermaciej> | HTTP isn't in nearly as bad shape as SVG |
22:29 | <hober> | I'm all for interoperable error handling -- if someone wants to write up "what the UFP does" in spec form, that would be potentially good |
22:29 | <othermaciej> | WS-* and RDF are of no interest to me |
22:30 | <tantek> | hsivonen, othermaciej - I believe the proper term is WS-death-* |
22:30 | <othermaciej> | annevk: an error-recovering version of XML would be a significant incompatible break - not sure it's worth it |
22:30 | <annevk> | lots of mobile content already breaks in Opera because we don't do it |
22:31 | <annevk> | I think Webkit shipped in Nokia has therefore disabled XML for XHTML... |
22:31 | <tantek> | ah, "mobile content" |
22:31 | <tantek> | is that another oxymoron? |
22:31 | <annevk> | and feeds too |
22:31 | <annevk> | although with feeds it's mostly character encoding which most browsers seem to ignore... |
22:31 | <tantek> | btw, Hixie, you may want to de-add yourself from yourself: http://twitter.com/Hixie - that might be causing problems. |
22:31 | <annevk> | (on the HTTP level most implementations of XML are non-compliant) |
22:32 | <zcorpan> | it could possible to define graceful error handling for xml in a way that is compatible with xml 1.0 handling, although it wouldn't be possible to drop the internal subset (other than making it non-conforming) |
22:32 | zcorpan | thinks |
22:32 | <annevk> | yeah, internal subset is most of the complexity of XML |
22:33 | <zcorpan> | if new processors silently ignored internal subsets then they wouldn't be compatible with existing xml documents that rely on the internal subset |
22:33 | <zcorpan> | a lot of svg images do |
22:34 | <annevk> | it has to be supported obviously |
22:34 | <annevk> | all XML 1.0 content needs to remain working |
22:34 | <zcorpan> | indeed |
22:34 | <annevk> | and all wanabe XML 1.0 content will start working |
22:34 | <annevk> | in some way |
22:35 | <zcorpan> | an xml 1.0 processor should also be a conforming xml5 processor (i.e. error recovery should be optional) |
22:35 | <zcorpan> | (imho) |
22:36 | <annevk> | xml5 would be a superset |
22:36 | <annevk> | as xml1.1 will be mostly integrated as well |
22:36 | <annevk> | and namespaces for xml too |
22:37 | <othermaciej> | this all sounds like a lot of work |
22:37 | <othermaciej> | it's a wonder the web works at all |
22:37 | <zcorpan> | but things that are parse errors in xml 1.0 (and namespaces in 1.0) surely should continue to be (so that processors are allowed to stop)? |
22:38 | <annevk> | that would mean that a processor is allowed to stop at <?xml version="1.1"?> |
22:38 | <zcorpan> | yes |
22:38 | <annevk> | i'm not really sure what the value in that is |
22:39 | <hsivonen> | annevk: the value is creating an atmosphere of doubt about guarantees of non-XML 1.0 XML5 working |
22:39 | <hsivonen> | annevk: so people would still have an incentive to try to get things right |
22:39 | <hsivonen> | annevk: which would make the upgrade less damaging to users of XML 1.0 processors |
22:40 | <annevk> | i suppose |
22:40 | <hsivonen> | nn |
22:40 | <annevk> | i'll let the spec lawyering to you :) |
22:40 | <zcorpan> | hsivonen: nn |
22:52 | <KevinMarks> | SMIL got broken by the second rev 2 - the first rev was pretty good |
22:55 | <KevinMarks> | hober, what the UFP does is try really hard to clean things up - the 2500+ tests define what it does pretty well |
22:55 | <KevinMarks> | back-porting them to a spec would be difficult |
22:57 | <hober> | agreed |
22:58 | <KevinMarks> | the feed validator is probably a better practical tool than a spec |
22:58 | <othermaciej> | validators are useful to producers only if consumers match its behavior |
22:58 | <othermaciej> | and for that you need a spec and a test suite to throw at consumers |
22:59 | <KevinMarks> | well, UFP provides the test suite |
23:01 | <hober> | What I was thinking was that the wa1 parsing algorithm is a reverse-engineer of what is more-or-less the existing interoperable error recovery for parsing html. |
23:02 | <hober> | there's less in terms of existing interoperable behavior in the feed parsing world, so I'd say reverse-engineering the UFP's behavior into a "liberal feed parsing algorithm" a-la wa1 is a possibility |
23:05 | <Dashiva> | Atom is a bit easier to implement than XHTML2, though (and orthogonal to rss, too) |
23:15 | <Hixie> | tantek: Hixie1 and Hixie are different accounts |
23:22 | <tantek> | Hixie, but your twitter.com/Hixie appears to be subscribed to twitter.com/Hixie - Hixie1 had no friends/followers (until I added it moments ago) |
23:23 | <Hixie> | i can't seem to remove Hixie from Hixie |
23:23 | <Hixie> | not sure how that happened or how to remove it |
23:23 | <Hixie> | it doesn't appear on my friends list |
23:27 | <Hixie> | do we have a page somewhere that explains in detail why version syntax isn't needed? |
23:27 | <Hixie> | hsivonen, Lachy_? |
23:31 | <tantek> | Hixie, shouldn't the burden of proof be the opposite? |
23:31 | <tantek> | nothing is needed unless it can be demonstrated that it is |
23:31 | <zcorpan> | http://dbaron.org/log/2007-03#e20070325a |
23:32 | <Dashiva> | tantek: The widespread use of versioning in other cases will probably be used for that |
23:34 | <Hixie> | tantek: people give all kinds of arguments in favour of version syntax |
23:34 | <Hixie> | tantek: they're all bogus imho, but it would be nice to be able to point to a page that explains why isn't of having to rehash hsivonen's e-mail each time |
23:34 | <tantek> | then you need debunking of those arguments, not a general attempt at a proof against |
23:34 | <Hixie> | right |
23:34 | <tantek> | perhaps in FAQ form |
23:35 | <tantek> | we need the same thing for namespaces in general |
23:35 | <tantek> | debunking thereof |
23:51 | <zcorpan> | nn |
23:58 | <Hixie> | so a lot of spammers have started using whatwg stuff to seed their spam blogs and referral spam campaigns |
23:58 | <othermaciej> | weird |
23:59 | <Hixie> | what's really funny however is that i work for google |
23:59 | <Hixie> | and i report them internally |
23:59 | <Hixie> | which (a) kills their page rank, not only on that site, but on all related ones, and (b) gets their spam blogs deleted from sites like blogger. |