| 00:51 | <heycam`> | Hixie, thanks |
| 01:01 | <sayrer> | "just" use BEEP |
| 01:01 | <sayrer> | lol wut |
| 01:02 | <Hixie> | if the beep advocates can write a DOM API spec for BEEP, adapt BEEP to work in the browser same-origin security model, and convince browser vendors to implement it, I have no objections to it |
| 01:02 | <Hixie> | but i think it would still be good to have a simple protocol like websocket as well :-) |
| 01:03 | <Hixie> | (not necessarily websocket itself) |
| 01:03 | <sayrer> | yeah, that's basically my issue with the entire discussion |
| 01:04 | <sayrer> | I almost wrote a message asking maciej whether WebSocket prevented the design he was adovocating |
| 01:05 | <Hixie> | i figure we can add an optional second argument to the constructor, and have that be part of the handshake -- and if the server doesn't send back the same string, abort with a suitable error code. |
| 01:05 | <Hixie> | WebSocket-Subprotocol: or something |
| 01:05 | <Hixie> | maybe we can even get the IANA to give us a registry for subprotocol types |
| 01:05 | <sayrer> | I think rfc3117 is my favorite |
| 01:06 | <sayrer> | until it goes off into BEEP land |
| 01:06 | <sayrer> | it's like the finale of battlestar galactica |
| 01:06 | <doublec> | no spoilers please... |
| 01:06 | <doublec> | :) |
| 01:07 | <doublec> | for those of us in way behind tv land |
| 01:07 | <doublec> | i'll forever be anticipating rfc3117 references in msg now |
| 01:07 | <doublec> | s/msg/bsg |
| 01:08 | <sayrer> | fortunately there is nothing overt! |
| 01:08 | <doublec> | hehe |
| 01:09 | <sayrer> | mmm, this hybi list is intensely unproductive |
| 01:09 | <sayrer> | amazing |
| 01:09 | <sayrer> | I just don't get it |
| 01:10 | <sayrer> | 1) solve the smallest problem you possibly can |
| 01:10 | <sayrer> | 2) declare victory |
| 01:10 | <sayrer> | 3) ??? |
| 01:10 | <sayrer> | 4) Profit! |
| 01:10 | <sayrer> | why do anything else? |
| 01:13 | <Hixie> | sayrer: a lot of the people on that list are already on step 4 and are wondering why we are talking about changing their steps 1 and 2 |
| 01:14 | <sayrer> | Hixie, are you being sympathetic to me or them? |
| 01:14 | <Hixie> | neither :-) |
| 01:15 | <Hixie> | i believe that a lot of the pushback we're getting is because there is already a thriving business around these involved protocols |
| 01:15 | <sayrer> | good point |
| 01:15 | <sayrer> | maybe we should ask for a new WG |
| 01:17 | <sayrer> | "The good thing about reinventing the wheel is that you can get a round one." |
| 01:17 | <sayrer> | I rather like that quote |
| 01:18 | <sayrer> | and it was about XML vs JSON |
| 01:18 | <Hixie> | i'm reading rfc3117 again -- it feels like when you hit section 3.4 it suddenly goes from being a useful overview of the state of affairs to being an exercise in second system syndrome. |
| 01:20 | <sayrer> | yeah |
| 01:26 | <sayrer> | but it's great because it is 8 years old and still a useful overview |
| 09:01 | annevk5 | joins the hybi discussion but isn't sure he should've done so |
| 09:02 | annevk5 | wonders what http://twitter.com/kevinwhinnery/statuses/1511868625 is about |
| 09:12 | <MikeSmith> | zcorpan: yeah, I noticed the sub/sup case also |
| 09:13 | <MikeSmith> | zcorpan: dealing with those actually turns out to be a major PITA |
| 09:14 | <MikeSmith> | at least for someone like me with limited coding skills |
| 09:14 | <MikeSmith> | but I messed around with it again today and have a fix |
| 09:14 | <zcorpan> | MikeSmith: the spec should be less human readable and be easier to scrape |
| 09:14 | <MikeSmith> | he |
| 09:14 | <MikeSmith> | heh |
| 09:14 | <MikeSmith> | yeah |
| 09:14 | <MikeSmith> | Hixie: please optimize the script for scraping! |
| 09:14 | jgraham | sees reams of hiby discussion, hopes that it is not too interesting |
| 09:15 | <jgraham> | s/hiby/hybi/ |
| 09:15 | <zcorpan> | MikeSmith: you can look for <dl class="element"> and its previous element sibling |
| 09:15 | <zcorpan> | s/element/heading element/ |
| 09:16 | <MikeSmith> | I could, but it'd mean more rewriting and testing to make sure I didn't break stuff |
| 09:16 | <MikeSmith> | zcorpan: it would be slightly easier if Hixie consistently used id=the-foo-element for all element h4s |
| 09:16 | <annevk5> | jgraham, it seems mostly about bidirectional HTTP / BEEP vs something close but not quite raw TCP sockets |
| 09:16 | <MikeSmith> | zcorpan: though that wouldn't work for h1-h6 or sub/sup case |
| 09:17 | <annevk5> | jgraham, obviously these two are pretty far apart so the discussion isn't really going anywhere |
| 09:19 | <jgraham> | annevk5: Oh. Well I guess it is safe to ignore for a while at least then |
| 09:33 | <annevk5> | http://twitpic.com/3aqou |
| 09:42 | <annevk5> | http://decafbad.com/blog/2009/04/13/i-like-revcanonical so besides that we're trying to remove rev, isn't canonical meant to be same-origin? |
| 10:08 | <hsivonen_> | annevk5: is this rev=canonical different from Google/Y!/MS rel=canonical? |
| 10:09 | <hsivonen_> | magic 8 ball says Web authors won't be able to use the distinction of rel and rev right here |
| 10:09 | <annevk5> | it is |
| 10:10 | <annevk5> | something like rel=shorturl would be better I think |
| 10:11 | <hsivonen_> | I can imagine all sorts of blog posts about evil HTML5 raining on the rev=canonical backpattery parade |
| 10:11 | <svl> | Mostly (from what I've seen) it's been "let's all use this en-masse, so html5 will be forced to include this". |
| 10:12 | <annevk5> | there's that too, but mostly using it just doesn't really add up |
| 10:12 | <annevk5> | canonical is for resource equivalence, not URL-after-redirect equivalence; canonical also has a same-origin restriction |
| 10:13 | <hsivonen_> | the tinyurl centralization problem would be mostly solved if twitter just showed the real URLs in tweets on every medium except the ephemeral SMSs |
| 10:24 | <Philip`> | I've seen quite a few people starting to use TinyURL in blog comments and blog posts and other places where it's completely unnecessary |
| 10:27 | <annevk5> | i blogged about rev=canonical; lets see if someone picks it up |
| 10:27 | <annevk5> | maybe in a few years all standards will be made through blogging |
| 10:28 | hsivonen_ | mumbles about feed autodiscovery |
| 10:28 | <annevk5> | true that :) |
| 10:29 | <annevk5> | would be nice if rel=feed got some more impl love |
| 10:34 | <annevk5> | rel=canonical too btw |
| 10:35 | <annevk5> | there's also http://revcanonical.appspot.com/ |
| 10:36 | <annevk5> | and apparently someone added "short" to http://wiki.whatwg.org/wiki/RelExtensions |
| 10:41 | <hsivonen_> | why am I not seeing the standards suck guy in Minefield on Anne's blog? |
| 10:44 | <annevk5> | does Minefield support SVG referenced from 'content'? |
| 10:58 | <annevk5> | heycam, FYI, empty string is fine for ID because an empty ID cannot exist |
| 10:59 | <heycam> | annevk5, fine with me, was just looking for it being defined one way or the other |
| 11:04 | <annevk5> | heycam, yeah, weird omission (it's defined for all other DOMString reflecting thingies) |
| 11:14 | Philip` | sees http://o-micron.blogspot.com/ (with some storage-related stuff) |
| 11:15 | <annevk5> | that's from the Oracle guy who's in favor of something like Atom for storage, no? |
| 11:18 | <Philip`> | Looks like it probably is |
| 11:18 | <hsivonen_> | annevk5: I don't know if Minefield is supposed to support SVG in CSS 'content' |
| 11:19 | <hsivonen_> | looks like the XHTML2 WG rep used the wrong name for their WG: http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0037.html |
| 11:19 | <annevk5> | they call themselves the XHTML WG quite often |
| 11:19 | <annevk5> | and call us the HTML5 WG |
| 11:20 | <annevk5> | "us" being the HTML WG, not the WHATWG |
| 11:20 | <annevk5> | whenever that happens I wonder if it's on purpose |
| 11:21 | <jgraham> | I always assume that it is on purpose |
| 11:22 | <annevk5> | outside the W3C it's often referred to as the HTML5 WG as well |
| 11:23 | <Philip`> | Maybe it's to disambiguate from the old HTML WG |
| 11:25 | <jgraham> | Somebody should teach the Oracle guy the golden rule of academic qualifications, which is that you should never, ever put them after your name |
| 11:25 | <Philip`> | What about putting them before your name? |
| 11:25 | jgraham | was waiting for that |
| 11:26 | <Philip`> | Or in the middle of your name? |
| 11:26 | <Philip`> | John "Dr" Smith, etc |
| 11:27 | <jgraham> | Philip`: At least nobody can be expected to take those things seriously |
| 11:27 | <Philip`> | What if you skip the name entirely and just call yourself Doctor? |
| 11:27 | <jgraham> | Although they have roughly the same effect of making you look like a right twat |
| 11:28 | <jgraham> | Philip`: Only works if you are a time lord |
| 11:30 | hsivonen | assumes that "some browsers" in ARIA is an euphemism for IE |
| 11:31 | <annevk5> | yeah... |
| 11:33 | <annevk5> | hsivonen, thanks for replying to that XHTML2 WG comment btw |
| 11:33 | <annevk5> | I was wondering whether I should do it |
| 11:34 | <hsivonen> | annevk5: I almost wrote feedback about the same spec sentence before seeing the XHTML2 WG comment. |
| 11:35 | <hsivonen> | the name "ARIA Best Practices" irks me. ARIA is so new, I don't believe Best Practices have emerged yet |
| 11:35 | <hsivonen> | should be Authoring Guide or something like that |
| 11:36 | <hsivonen> | Best Practices and Guidelines are weasel words in general |
| 11:36 | <annevk5> | if it ever gets widely adopted :/ |
| 12:14 | <zcorpan> | what's focal locus? |
| 12:16 | <hsivonen> | zcorpan: the point of focus? |
| 12:21 | <virtuelv> | "In mathematics, a locus (Latin for "place", plural loci) is a collection of points which share a property. " |
| 12:22 | <virtuelv> | http://en.wikipedia.org/wiki/Locus_(mathematics) |
| 12:47 | hsivonen | has 63 public-pfwg-comments autoreplies |
| 13:07 | <annevk5> | I complained about that and was told it was a special list :/ |
| 13:08 | <jgraham> | The pfwg list is insane. I can only imagine that the point of it is to deter comments on the spec |
| 13:09 | annevk5 | has to run |
| 13:47 | <remysharp> | A question about <article> - I've seen in examples that <article> is nested within a <section> - but the page I put together goes as: <article><section> - is there any specific reason I might be wrong, or is it actually down to content layout? |
| 13:48 | <jgraham> | remysharp: That is good and more likely sounding than the other way around |
| 13:49 | <remysharp> | sorry - just to be clear are you saying that it *should* be <article><section> then? |
| 13:50 | <jgraham> | e.g. <article><h1>A Celebrity Did Something</h1><section><h2>Summary</h2></section><section><h2>So civilization will end</h2></section></article> |
| 13:50 | <remysharp> | perfect - that's what I understood the spec to mean. |
| 13:50 | <remysharp> | cheers for that. |
| 13:51 | <jgraham> | remysharp: Neither way is "right" it's just more obvious why an article would have multiple <section>s than a <section> would have multiple articles |
| 13:52 | <jgraham> | (an example of the latter could be <body><h1>The News</h1><section><h2>Celebrity News</h2><article><h3>A Celebrity Did Something</h3>[...] |
| 13:53 | <remysharp> | Aye, sure. that makes sense, and that's what I understood. |
| 13:53 | <remysharp> | I've just come across quite a few examples that used the article for smaller chunks, and I wasn't completely clear why (when they may have been related to later chunks of content). |
| 13:55 | <jgraham> | remysharp: The wwonderful thing about sematics is that there are so many of them to choose from |
| 14:01 | <remysharp> | jgraham: agreed - thanks again for the advice. |
| 20:19 | <annevk5> | http://www.mnot.net/blog/2009/04/14/rev_canonical_bad is a slightly better explanation of the rev=canonical problem |
| 20:21 | <annevk5> | I think I agree with rubys that it would be good to indicate in HTML5 which attributes and elements are obsolete (they're not deprecated). But I also thought that it was planned already. Anybody who knows? |
| 20:43 | <Hixie> | annevk5: anything that isn't in html5 is obsolete |
| 20:58 | <Philip`> | Hixie: That seems to unhelpfully ignore the distinction between things that used to have some meaning in HTML and are not in HTML5, and things that have never had any meaning at all in HTML |
| 20:58 | <Philip`> | (e.g. <link rev> vs <link wlkthglkrh>) |
| 20:58 | <Hixie> | not sure why that distinction is needed |
| 20:59 | <Philip`> | People will see <link rev> being used somewhere, then look in the latest HTML spec to see what it is, and encounter a complete absence of information, which is less helpful to them than a note that it was defined in some other spec and has been omitted for whatever reasons |
| 21:03 | <Hixie> | *shrug* |
| 21:03 | <Hixie> | if someone wants to make a list of features that should have such notes, file a bug and i'll add it somewhere |
| 21:03 | <Philip`> | (Even people who fully understand the HTML5 process won't be able to deduce that <link rev> was omitted from HTML5 when they fail to find any references to it, since it might just be that they're searching in the wrong section) |
| 21:04 | <Philip`> | (or they might be using Opera which seems to have bugs in its search feature that make it miss things in the spec) |
| 21:10 | <tantek> | Hixie, HTML 4.0 has the notion/label of "Obsolete" for features that have been outright dropped from the previous version 3.2 (in contrast to "Deprecated", meaning, still supported but discouraged). |
| 21:10 | <tantek> | http://www.w3.org/TR/html4/appendix/changes.html#h-A.3 |
| 21:11 | <Hixie> | like I said, I don't mind listing some obsolete features if people want. There's already some level of that in the "downplayed errors" list |
| 21:12 | <tantek> | It may be reasonable for HTML4 to have a similar "changes from HTML4.01" section with a list of such "Obsolete" elements and attributes, optionally with a short description or link to why it was dropped etc. |
| 21:12 | <tantek> | er, reasonable for HTML5 to have a similar ... section |
| 21:13 | <tantek> | Hixie, as we're tangentially on the rev subject, do you have a canonical post somewhere with the summary of the poor usability in practice of the "rev" attribute? |
| 21:13 | <tantek> | The best I've written up so far is: http://microformats.org/wiki/rev#Should_rev_even_be_used |
| 21:14 | <tantek> | which cites your http://code.google.com/webstats/2005-12/linkrels.html |
| 21:14 | <tantek> | anything newer/better? |
| 21:15 | <Philip`> | http://philip.html5.org/data/link-rel-rev.txt has some newer data |
| 21:15 | <Hixie> | i don't think i have written anything up other than mails to the whatwg list |
| 21:17 | <tantek> | I particularly like <link rev="1.02" ...> |
| 21:17 | <tantek> | (from Philip`s URL) |
| 21:18 | <tantek> | at least vote-links show up in Philip`s data ("vote-for", "vote-against", "vote-abstain") |
| 21:19 | <sayrer> | 2 <link rev="argonet" ...> |
| 21:19 | <sayrer> | weird |
| 21:19 | <sayrer> | 1 <link rev="D. Bailey Management" ...> |
| 21:21 | <Hixie> | the long tail of markup oddities is very long on the web |
| 21:21 | <Hixie> | very |
| 21:21 | <Hixie> | very |
| 21:21 | <Hixie> | long |
| 21:25 | <tantek> | Thanks Philip`. I've added that URL to http://microformats.org/wiki/rel-faq#Should_rev_even_be_used |
| 21:39 | <takkaria> | argonet? heh, I wonder how that ende up there |
| 21:42 | <Philip`> | http://www.comune.barzago.lc.it/ - <link rev="argonet" href="http://www.argonet.it/"; title="Sviluppato da Argonet: comunicazione, web design, consulenza e sviluppo."> |
| 21:43 | <Philip`> | http://www.comune.tremenico.lc.it/ too |
| 22:58 | Hixie | finds himself writing long winding sentences and wonders if maybe half way through he should plant a signpost with a map and "you are here" |
| 23:37 | <MikeSmith> | about http://krijnhoetmer.nl/irc-logs/whatwg/20090414#l-407 - validator.nu has some special handling/reporting of a few obsolete elements |
| 23:37 | <MikeSmith> | e.g., http://validator.nu/?=&doc=http://dev.w3.org/html5/tests/validation/full/invalid/obsolete/center.html |
| 23:39 | <MikeSmith> | it reports them as "Error: The center element is obsolete." |
| 23:40 | <MikeSmith> | whereas it would otherwise report them as "Error: Element center not allowed as child of element body in this context." |
| 23:47 | <sayrer> | the center element is obsolete? |
| 23:47 | <MikeSmith> | it is in the HTML5 draft, yeah |
| 23:47 | <sayrer> | obsolete, works great, news at 11 |
| 23:47 | <Hixie> | it doesn't work great |
| 23:47 | <Hixie> | it's like the <font> element |
| 23:48 | <Hixie> | leads to terribly inaccessible sites |
| 23:48 | <Hixie> | and is a maintenance nightmare |
| 23:48 | <Hixie> | even HTML4 acknowledges that |
| 23:48 | <sayrer> | maintenance nightmare doesn't seem like a good argument |
| 23:48 | <Hixie> | to you maybe :-) |
| 23:48 | <sayrer> | since the alternatives are still available |
| 23:48 | <MikeSmith> | sayrer: it's not valid in XHTML strict either, right? |
| 23:48 | <sayrer> | XHTML is not relevant to me |
| 23:49 | <sayrer> | (or anyone else on the Web, but I digress) |
| 23:49 | <sayrer> | Hixie, how does it lead to inaccessible sites? |
| 23:50 | <MikeSmith> | <center> is not in HTML 4.01 strict either |
| 23:51 | <Hixie> | sayrer: it scares me that you are editing an html specification and are asking that question |
| 23:51 | <sayrer> | well, that's not really an answer |
| 23:52 | <Hixie> | i really don't have the time to teach you elementary web design, sorry |
| 23:52 | <Hixie> | i'm sure you can find a plethora of tutorials on the subject on the web though |
| 23:53 | <sayrer> | I have seen many examples of the font element being used in an inaccessible fashion |
| 23:53 | <MikeSmith> | anyway, fwiw, the way the obsolete-element handling is implemented in v.nu is that the obsolete elements are part of the v.nu/whattf HTML5 RelaxNG schema -- treated as valid (that's the only way to get the schema to recognize them -- but an additional assertions-checking step further along in the processing pipeline then catches and reports them |
| 23:53 | <sayrer> | but why is it different than an equivalent style attribute? |
| 23:54 | <Hixie> | it's not. style="" attributes are just as bad and should be limited to things like prototyping and temporary workarounds. |
| 23:55 | <sayrer> | Hixie, ok, is style="" obsolete in HTML5 as well? |
| 23:55 | <Hixie> | it was, for a long time. there are some edge cases for which it is useful (primarily prototyping), which is why it is currently allowed. |
| 23:56 | <sayrer> | Hixie, <font> works better for fragments |
| 23:56 | <sayrer> | sad but true, perhaps |
| 23:57 | <Hixie> | i really am not interested in arguing this case right now; i need to finish the <datagrid> redesign. |
| 23:57 | <Hixie> | there are ample essays on the subject on the web that can enlighten you on the subject though. |
| 23:57 | <sayrer> | well, no one invited you to argue it. carry on! |