| 01:30 | <TabAtkins> | othermaciej: FWIW, that *was* me trying to be as civil as possible. |
| 01:32 | <TabAtkins> | Of course, now we'll probably be treated to another round of thinly-veiled accusations of sexism on alternate content streams. |
| 01:32 | <TabAtkins> | Sigh. You just can't win when your opponent is certain that you're evil and wrong. |
| 01:32 | <othermaciej> | TabAtkins: just try not to pour fuel on the fire |
| 01:33 | <othermaciej> | I recognize that Shelley's tone went somewhat hostile, but a statement like "Also, seriously, chill" seems more likely to escalate the conflict than to cool it off, given the history |
| 01:34 | <TabAtkins> | Heh, that was meant as an amusing callback to our previous exchange. |
| 01:34 | <TabAtkins> | I decided to forgo the smilie this time, as that seems to have the opposite effect of what is intended. |
| 01:38 | <othermaciej> | I expect Shelley was not amused, and I also think you could have predicted that she would not be amused |
| 01:38 | <othermaciej> | I don't mean to be a hardass here, just giving the usual "no fighting in the war room" admonition |
| 01:42 | <estellevw> | inquiring minds want to know: where was the drama? |
| 01:42 | <Hixie> | public-html as always |
| 01:45 | <TabAtkins> | othermaciej: I am *seriously* not trying to fan any flames with my latest email. Apologies if anyone does still get mad. ;_; |
| 01:45 | <othermaciej> | now with up to 80% less drama! |
| 01:46 | <othermaciej> | just don't make me come back there |
| 01:47 | <TabAtkins> | You shouldn't have to, unless Shelley gets offended again. I'm really trying to be as nice as possible here (as opposed to before, when I was being as nice as reasonable). |
| 01:49 | <Hixie> | what exactly are you proposing? I must have skipped past the part of the thread where you suggested something |
| 01:49 | <TabAtkins> | I asked her to remove the points from her rationale that are solely arguments against @sandbox, rather than against @srcdoc. |
| 01:50 | <Hixie> | oh |
| 01:51 | <Hixie> | well hell, we wouldn't want her to make her proposals more readable, they'd be more likely to pass! |
| 01:51 | <Hixie> | why are you suggesting such a thing |
| 01:51 | <Hixie> | oh wait, i get it, it's reverse psychology! very clever |
| 01:51 | <TabAtkins> | Because I have an irrational urge to make the process actually work as intended. |
| 01:52 | <Hixie> | you must be new here |
| 01:52 | <Hixie> | :-P |
| 01:52 | <Hixie> | ah well. we'll have you turned into a cynic soon enough. no need to rush it i guess. |
| 01:52 | <TabAtkins> | I'm a cynical idealist. Why isn't this good enough? |
| 01:52 | <TabAtkins> | Anyway, out for the night. |
| 01:53 | <Hixie> | later |
| 03:13 | <TabAtkins___> | Hixie, brainstorming about timed text markup formats. What were the extensions you were thinking of for timestamps and stage directions in <dialog>? |
| 04:13 | <MikeSmith> | Hixie: about http://www.w3.org/Bugs/Public/show_bug.cgi?id=9472 (deal with broken links in dynamic author view of spec by prompting users to choose to switch to full view) |
| 04:13 | <MikeSmith> | did you deploy a change for that already? |
| 04:48 | <boblet> | anyone know if Arabic Taškīl, Hebrew Niqqud, or other non-CJK languages would use ruby for marking up phonetic annotations or diacritics? |
| 04:59 | <MikeSmith> | boblet: Richard Ishida would know |
| 05:00 | <MikeSmith> | I seem to remember some examples in ruby supplementary docs of non-Chinese/Japanese languages that had ruby annotations |
| 05:00 | <MikeSmith> | but I dunno remember where |
| 05:00 | <boblet> | MikeSmith: you’ll be thinking of the dodgy abbreviation WWW and expiry date in Ruby Annotation I bet |
| 05:01 | <boblet> | yeah I need to ping Richard, he’d definitely know. will email him |
| 05:01 | <MikeSmith> | ? |
| 05:02 | <boblet> | abbr as ruby: http://www.w3.org/TR/ruby/#simple-ruby1 |
| 05:02 | <boblet> | ruby as formatting hack: http://www.w3.org/TR/ruby/#complex |
| 05:03 | <boblet> | MikeSmith: apart from that I’ve only found Chinese & Japanese examples. I can’t even determine if Korean use hangul ruby with hanzi or not |
| 05:04 | <MikeSmith> | boblet: I have never seen any examples of hanzi with ruby |
| 05:04 | <MikeSmith> | but I don't encounter a lot of Korean text anyway |
| 05:05 | <boblet> | MikeSmith: me neither, so wondering if they just don’t do it. South Korea is basically moving to all hangul, but I think they still use about 1000 hanzi. North Korea supposedly completely stopped teaching them in like the 60s but then reintroduced them due to Chinese |
| 05:06 | <boblet> | don’t know any Koreans I can ask :( |
| 05:06 | <MikeSmith> | they still use a lot of hanzi in Korean, from what I have seen while visiting there |
| 05:06 | <MikeSmith> | e.g., many buildings have names written in hanzi and such |
| 05:07 | <MikeSmith> | and 20-years-olds or so still know many kanji |
| 05:07 | <MikeSmith> | I think they still teach them in high school |
| 05:08 | <MikeSmith> | but I suspect in Korean the logograms all have only a single reading |
| 05:09 | <MikeSmith> | so the reading is unambiguous, and they wouldn't need ruby for showing phonetic readings |
| 05:09 | <MikeSmith> | I think |
| 05:10 | <boblet> | well, assuming you know how to read them ;-) wonder if they have hanzi/hangul/romanisation on eg train signs. don’t remember |
| 05:11 | <paul_irish> | boblet: what are you writing that article on? |
| 05:11 | <boblet> | paul_irish: HTML5 ruby, for HTML5Doctors |
| 05:11 | <paul_irish> | ruby! sweeet |
| 05:11 | <boblet> | it’s killing me >_< |
| 05:12 | <paul_irish> | ruby and rt are so sexy |
| 05:12 | <boblet> | emoticon fail that should be the Japanese ＞＿＜ emoji |
| 05:12 | <boblet> | paul_irish: like I said, i18n and a11y are bad enough on their own. combining them |
| 05:12 | <boblet> | ouch |
| 05:43 | <MikeSmith> | http://webkit.org/blog/1091/more-web-inspector-updates/ |
| 05:43 | <MikeSmith> | cool stuff |
| 05:56 | <MikeSmith> | boblet: can you think of a Japanese equivalent of "Eeny, meeny, miny, moe"? |
| 05:56 | <MikeSmith> | oh |
| 05:56 | <MikeSmith> | found it |
| 05:57 | <MikeSmith> | eigiro to the rescue |
| 05:57 | <MikeSmith> | http://eow.alc.co.jp/Eeny/UTF-8/?ref=sa |
| 05:57 | <MikeSmith> | hmm, it's only an explanation |
| 05:58 | <MikeSmith> | doesn't say what equivalent if any there is |
| 06:10 | <wirepair> | doesn't everyone just do junken? |
| 06:10 | <wirepair> | oh nevermind, you mean for selecting somethign ;> |
| 06:18 | <MikeSmith> | wirepair: yeah, for picking somebody to be "it" |
| 06:18 | <wirepair> | mike, just asked a friend they do the same thing 'do re ni shi yo u ka na' |
| 06:18 | <wirepair> | ten no ka mi sa ma |
| 06:18 | <wirepair> | ... |
| 06:18 | <wirepair> | etc |
| 06:19 | <wirepair> | so what is in that alc description is right hehe |
| 06:19 | <MikeSmith> | intersting |
| 06:19 | <MikeSmith> | I guess I can ask my daughter too |
| 06:19 | <MikeSmith> | for an authoritative |
| 06:19 | <MikeSmith> | viewpoint |
| 06:19 | <MikeSmith> | since she must use something when playing kakurembo etc. |
| 06:20 | <wirepair> | i just found out they do the same thing with flower petals |
| 06:21 | <wirepair> | he seemed really surprisd we do it too ;> |
| 06:21 | <wirepair> | surprised rather |
| 06:56 | <Hixie> | MikeSmith: yes |
| 06:56 | <Hixie> | MikeSmith: (re the links in author mode thing) |
| 07:00 | <MikeSmith> | Hixie: what's the expected behavior? |
| 07:00 | <MikeSmith> | does it pop up a prompt? |
| 07:00 | <Hixie> | yeah |
| 07:00 | <MikeSmith> | Ok |
| 07:00 | <MikeSmith> | I'll have to try again |
| 07:01 | <MikeSmith> | I tried in Webkit and Minefield and it didn't seem to work |
| 07:01 | <Hixie> | hm |
| 07:01 | <Hixie> | what were you trying? |
| 07:02 | <MikeSmith> | I'm trying clicking on the links in the IDLs |
| 07:10 | <Hixie> | on what page? |
| 07:11 | <zcorpan> | it only seems to work when loading the page with a broken fragment, not loading then clicking a broken link |
| 07:14 | <Hixie> | make sure the browser you are using supports the 'hashchange' event |
| 07:22 | <zcorpan> | ok, works fine for me in chrome |
| 07:44 | <myakura> | Hixie: I got a comment in the public-html-ig-jp which asks whether <figcaption> can have flow content inside: http://lists.w3.org/Archives/Public/public-html-ig-jp/2010Apr/0010.html |
| 07:44 | <Hixie> | Content model: |
| 07:44 | <Hixie> | Phrasing content. |
| 07:44 | <Hixie> | so no. |
| 07:45 | <myakura> | I guess so. Then the example in http://www.whatwg.org/html5#table-descriptions (labbeled "Next to the table, in a figure's figcaption") is wrong :) |
| 07:46 | <Hixie> | oh, good point |
| 07:46 | <Hixie> | i'll file a bug, thanks |
| 07:46 | <zcorpan> | wait what, didn't we change the content model to flow before? |
| 07:46 | <zcorpan> | when it was called <legend> |
| 07:46 | <Hixie> | it probably changed back when i made it <dt> |
| 07:47 | <zcorpan> | it should allow flow, since there are use cases for it (same as <caption>) |
| 07:48 | <Hixie> | already filed the bug |
| 07:50 | <zcorpan> | ok, first i thought you wanted to change the example |
| 07:51 | <Hixie> | ah, no, sorry for the confusion |
| 07:52 | myakura | was about to reply that the example was wrong. phew. |
| 07:55 | <zcorpan> | Hixie: why does send() return a boolean? it seems the browser could return true but the sending will still fail (e.g. because the server has closed the connection before the data is actually sent) |
| 07:55 | <zcorpan> | Hixie: a more reliable check would involve looking at wasClean and bufferedAmount, and then the return value of send() seems useless |
| 07:56 | <Hixie> | the return value is just to help you if you're sending data on a timeout, i think |
| 07:56 | <Hixie> | it's a coarse and blunt instrument |
| 07:57 | <zcorpan> | what does help with? |
| 07:59 | <Hixie> | come again? |
| 07:59 | <zcorpan> | i mean, why do we have a boolean return value at all? what problem does it solve? |
| 08:00 | <Hixie> | someone asked for it at some point |
| 08:00 | <Hixie> | it seemed harmless to provide |
| 08:00 | <Hixie> | i forget the details |
| 08:06 | <Hixie> | fixed figcaption to be flow |
| 08:06 | <Hixie> | i am so not looking forward to working out how Selection.modify() works |
| 08:08 | <MikeSmith> | Hixie: OK, I see (about the link pop-up feature) |
| 08:08 | <MikeSmith> | thanks |
| 08:08 | <Hixie> | np |
| 08:08 | <Hixie> | if you know how to make it work in other browsers let me know |
| 08:09 | <Hixie> | should work at least in chrome and ie |
| 08:09 | <MikeSmith> | what browsers suppor the hashchange event? IE and CHrome? |
| 08:09 | <MikeSmith> | kk |
| 08:12 | <zcorpan> | Hixie: you could listen for click events |
| 08:13 | <zcorpan> | Hixie: although personally i'd just wait for browsers to implement hashchange :) |
| 08:14 | <MikeSmith> | yeah |
| 08:15 | <MikeSmith> | this gives other browser projects some good incentive to implement it |
| 08:21 | <myakura> | MikeSmith: so how was the tv show? did you watch it? |
| 08:23 | <MikeSmith> | myakura: it's actually on tonight |
| 08:23 | <MikeSmith> | at 11:30 |
| 08:26 | <myakura> | MikeSmith: d'oh. I thought it was 14th. |
| 08:39 | <Hixie> | i actually thought everyone did hashchange when i implemented it, i woulda checked otherwise :-) |
| 08:52 | <JonathanNeal> | ben_alman wrote a pretty good program for detecting hash changes. |
| 08:53 | <JonathanNeal> | May not be at all what you're talking about or looking for, but just in case http://benalman.com/projects/jquery-bbq-plugin/ |
| 08:53 | <zcorpan> | http://yfrog.com/06h39aj |
| 08:54 | <zcorpan> | w00t http://www.apple.com/euro/itunes/charts/apps/top10appstorefree.html |
| 08:55 | <JonathanNeal> | yea that's pretty awesome for Opera. |
| 08:55 | <hsivonen> | zcorpan: something wrong with Australia :-) |
| 08:56 | <zcorpan> | hsivonen: yeah, what's up there |
| 08:57 | <JonathanNeal> | I dunno, they were Opera earlier today. |
| 08:57 | <JonathanNeal> | They love their birds, I guess. |
| 08:57 | <annevk> | tweeted |
| 08:58 | <JonathanNeal> | I saw Opera on there the other day, it was so freaking fast and snappy. |
| 08:58 | <annevk> | or twitted or ... |
| 08:58 | <othermaciej> | neat! |
| 08:58 | <othermaciej> | though it makes me want to download Bird Strike |
| 08:58 | <JonathanNeal> | Don't do it! It's #2 in the US. |
| 09:17 | <MikeSmithX> | Hixie: I recommend mixing around your browser usage now and then :p |
| 09:17 | <MikeSmithX> | your hashchange assumption is a clear sign that you are secretly a dedicated IE user/fanboy |
| 09:18 | <JonathanNeal> | isn't everybody an ie fanboy |
| 09:18 | <zcorpan> | i wonder if ie copes with complete.html |
| 09:29 | <MikeSmith> | I just got a great error message from my IMAP server via mutt : "Too many consecutive protocol violations." |
| 09:30 | <MikeSmith> | Hixie, othermaciej - I'm thinking of setting up a mailbot that automatically raises bugzilla bugs for all new messages posted to public-html-comments |
| 09:31 | <othermaciej> | MikeSmith: hmmm |
| 09:31 | <MikeSmith> | where new = does not have an In-reply-to or References header |
| 09:31 | <MikeSmith> | othermaciej: bad idea? |
| 09:31 | <Hixie> | you're gonna have to hire someone else to help me with dealing with the noise if you do that |
| 09:31 | <othermaciej> | I'm thinking about whether typical emails to that list make for a good bug |
| 09:31 | <MikeSmith> | hmm, OK |
| 09:31 | <othermaciej> | I think a lot of the emails there have one of the following properties: |
| 09:32 | <othermaciej> | - really an idea for discussion, not an actionable problem report |
| 09:32 | <othermaciej> | - include large numbers of potentially separate issues |
| 09:32 | <othermaciej> | there have also been comments against different specs |
| 09:32 | <MikeSmith> | ok |
| 09:32 | <MikeSmith> | point taken |
| 09:32 | <othermaciej> | I don't know if I have seen a single one that would meet all our criteria for good info to put in a bug report |
| 09:33 | <MikeSmith> | clearly some human needs to be in the decision pipe |
| 09:33 | <othermaciej> | maybe an on-demand version of this tool would be useful |
| 09:33 | <othermaciej> | where it's easy for some trusted set of people to convert a public-html-comments email into a bug |
| 09:33 | <MikeSmith> | yeah |
| 09:33 | <MikeSmith> | that's a better approah |
| 09:33 | <MikeSmith> | *way |
| 09:34 | <MikeSmith> | just thinking about how we handle comments on that list after we start LC |
| 09:35 | <othermaciej> | lots of actual discussion there too, at least in the past month :-/ |
| 09:35 | <othermaciej> | I think our Last Call statement needs to indicate that the way to give a Last Call comment and get a response is to file a bug |
| 09:35 | <MikeSmith> | I would be very happy with that |
| 09:35 | <MikeSmith> | would make all our lives a lot easier |
| 09:35 | <othermaciej> | Paul Cotton seemed to indicate that this was seen as acceptable in the past for other WGs |
| 09:36 | <MikeSmith> | yeah |
| 09:36 | <MikeSmith> | so let's do that |
| 09:36 | <MikeSmith> | make it the responsibility of the commenter to actually raise the bug themselves |
| 09:36 | <MikeSmith> | now that I say that, that's the only way the really makes sense anyway |
| 09:36 | <MikeSmith> | raising bugs on behalf of somebody else is not a good idea |
| 09:38 | <hsivonen> | will public-html-comments be closed down with all comments directed to bugzilla? |
| 09:46 | <annevk> | what does tl;dr mean in email context? |
| 09:46 | <annevk> | is it like ignored and deleted or some such? |
| 09:47 | <annevk> | (see hybi for an example) |
| 09:47 | <othermaciej> | in general it means "too long; didn't read", but responding to an email on a standards list that way is kind of ridiculous |
| 09:47 | <annevk> | aah, what an asshole |
| 09:49 | <MikeSmith> | hmm, http://www.w3.org/XML/2010/04/xml-model/ .. "This document allows schemas using any schema definition language to be associated with an XML document by including one or more processing instructions with a target of xml-model in the document's prolog" |
| 09:51 | <MikeSmith> | annevk: careful, that dude was 'nominated one of the "50 most influential people in IP" by Managing Intellectual Property magazine' |
| 09:51 | <MikeSmith> | so you better give him some due respect |
| 09:52 | <MikeSmith> | I wonder if that means he was nominated, but lost |
| 09:53 | <annevk> | heh |
| 09:55 | myakura | waves to annevk. welcome back :) |
| 09:55 | <MikeSmith> | "This specification is complementary technology which can be used when it is necessary to store ad-hoc schema associations directly inside XML document." |
| 09:56 | <annevk> | thanks myakura! nice to be back :) |
| 09:56 | <zcorpan> | is it a good idea to subscribe to hybi? |
| 09:57 | zcorpan | subscribes |
| 09:58 | <MikeSmith> | zcorpan: you still in the XML Core WG |
| 09:58 | <MikeSmith> | ? |
| 09:58 | <MikeSmith> | I think I'll file an editorial bug saying that they wrote "necessary" in the sentence above, when what they actually mean is "convenient" |
| 09:59 | <zcorpan> | MikeSmith: yes |
| 10:01 | <MikeSmith> | zcorpan: please beat some sense into those guys |
| 10:04 | <annevk> | zcorpan, no, but I guess you should |
| 10:05 | <hsivonen> | zcorpan: it may be a good idea only in the sense that subscribing to public-html is a good idea |
| 10:07 | <hsivonen> | I wonder what rock the hybi folks have been living under not to have seen code written very, very badly by Web authors |
| 10:08 | <othermaciej> | hsivonen: you don't have to look at content to serve it I guess... |
| 10:10 | <annevk> | http://twitter.com/benschwarz/statuses/12193163314 -- must have been inevitable that tweets like this would happen |
| 10:13 | <othermaciej> | annevk: I don't understand what he is responding to there |
| 10:14 | <othermaciej> | or what his question means... |
| 10:16 | <anarchos> | hi |
| 10:19 | <annevk> | othermaciej, yeah, not really sure either, but the implication seems to be that "those people" were also responsible for HTML4 |
| 10:20 | <othermaciej> | I think he's claiming that the people on the WHATWG list prevented progress in HTML after HTML4 |
| 10:20 | <othermaciej> | which is a very interesting reading of history |
| 10:21 | <annevk> | right |
| 10:23 | <Philip`> | othermaciej: "maybe an on-demand version of this tool would be useful" "where it's easy for some trusted set of people to convert a public-html-comments email into a bug" - how would the tool be more useful than simply copying-and-pasting into a bug report? |
| 10:24 | <othermaciej> | Philip`: fewer mouse movements? |
| 17:10 | zcorpan | files bugs on html5test |
| 17:10 | <zcorpan> | were there other things wrong other than the codecs? |
| 17:13 | <paul_irish> | he's been really active in development of the new version.. lots of fixes and changes have already went in |
| 17:13 | <paul_irish> | even moved some of the sections so people wouldnt miscontrue that they were part of html5.. |
| 17:20 | <zcorpan> | hmm i should have looked at trunk source instead of deployed source |
| 17:24 | <paul_irish> | zcorpan: and here's his thoughts on including codecs.. http://rakaz.nl/2010/03/the-html5-test.html#comment-1603 |
| 17:47 | <zcorpan> | "IE9 video tag should follow standard object fallback principals if this video is any indication: |
| 17:47 | <zcorpan> | http://live.visitmix.com/MIX10/Sessions/CL27"; -- http://www.cssquirrel.com/2010/03/22/comic-update-ie-nine-means-business/#comment-31899 |
| 17:48 | <zcorpan> | srsly? if that's true, microsoft are clearly incapable of implementing the spec |
| 18:12 | <zcorpan> | "if the video element fails for any reason, it'll fallback to teh contents inside" he says in the video |
| 18:12 | <zcorpan> | hrmm |
| 18:13 | TabAtkins | refuses to watch videos of talks, but will ping a friend over at MS for confirmation about what's happening there. |
| 18:27 | <AryehGregor> | I also hate videos of talks. |
| 18:27 | <AryehGregor> | Way too hard to skim. |
| 18:27 | <AryehGregor> | And audio. |
| 18:28 | <TabAtkins> | Yus. Both are my primary difficulties with the format. Gimme a transcript, much easier to use. |
| 18:28 | <TabAtkins> | Score another point for a11y's unintended positive effects! |
| 18:29 | AryehGregor | reflects on Chrome's decision to strip "http://" from the beginning of URLs in UI |
| 18:29 | <AryehGregor> | Seems to make sense. |
| 18:29 | <AryehGregor> | I don't really notice it. |
| 18:30 | <TabAtkins> | That hasn't made it to stable yet. I suppose I should follow dev channel. What's the easiest way to put myself on such? |
| 18:30 | <AryehGregor> | Google "Chrome dev channel" and follow the links? |
| 18:30 | <AryehGregor> | I've actually found it kind of annoying. |
| 18:31 | <AryehGregor> | It's a little too crashy/unstable. |
| 18:31 | <AryehGregor> | I'd switch to the beta channel if I weren't too lazy. |
| 18:31 | <TabAtkins> | kk |
| 18:31 | <AryehGregor> | You can switch to it easily, but switching back is trickier, I think. |
| 18:31 | <AryehGregor> | Not sure how well it works. |
| 18:32 | <TabAtkins> | Ah, nm, doesn't look like they have beta releases for linux? |
| 18:32 | <TabAtkins> | I guess I can run it on my W7 box. |
| 18:32 | <AryehGregor> | They only have beta and dev for Linux, last I checked. |
| 18:32 | <AryehGregor> | No stable. |
| 18:33 | <AryehGregor> | (beta != dev, of course) |
| 18:33 | <TabAtkins> | Yeah, dev is weekly pushes, beta is monthly, stable is quarterly. |
| 18:34 | <AryehGregor> | Something like that. |
| 18:34 | <AryehGregor> | I don't think that's precise, though. |
| 18:34 | <TabAtkins> | That's what I heard yesterday when one of our engineers asked what the update schedule was, at least. |
| 18:35 | <AryehGregor> | Why do Google people call programmers "engineers"? |
| 18:35 | <TabAtkins> | Dunno. |
| 18:35 | <AryehGregor> | Everyone at Google does it consistently, but like no one else does. |
| 18:36 | <TabAtkins> | That's just our term for some reason. We're all hired as "software engineers". |
| 18:36 | <AryehGregor> | Well, that's a very common term in bureaucrat-speak, but in most places normal people don't use it. |
| 18:36 | <TabAtkins> | Shrug. |
| 18:36 | <AryehGregor> | It sounds vaguely grandiose for some reason. Not sure why, since it's not like actual engineering is particularly harder or more prestigious or better-paying than software development. |
| 18:37 | <AryehGregor> | Maybe because it implies a kind of exactness and certainty that doesn't really exist in software. |
| 18:37 | <TabAtkins> | I suppose it was considered the most appropriate term that still covered all the different things that we hire people for, not all of which is programming. |
| 18:37 | <TabAtkins> | (Excluding non-technical things like advertising or sales or HR, obviously.) |
| 18:38 | <AryehGregor> | Maybe that's a flaw in the entire concept of job titles, then. I once heard (never checked) that the credits for Valve games mostly don't have titles. Just a long undifferentiated list of people. |
| 18:39 | <AryehGregor> | Because apparently they each do whatever they're interested in and good at doing. |
| 18:39 | <AryehGregor> | Or something. |
| 18:39 | <TabAtkins> | We don't really *have* job titles, except as a very generic slotting mechanism, like I said. Every single technical hire at Google is a "software engineer". Nothing more, nothing less. |
| 18:39 | <AryehGregor> | Interesting. |
| 18:40 | <AryehGregor> | http://www.mobygames.com/game/windows/half-life-2/credits |
| 18:40 | <hsivonen> | AryehGregor: I thhink it's standard practice elsewhere, too, not just at Google to treat "programmer" as a dirty word and call people software developers or software engineers |
| 18:40 | <TabAtkins> | Then we just get picked up by a particular team, and identify ourselves that way. We're encourage to move around between teams, though. |
| 18:40 | <AryehGregor> | Undifferentiated except for voices, face usage, and legal. |
| 18:40 | <AryehGregor> | hsivonen, "developers" I'm used to, "engineers" strikes me as a bit weird. |
| 18:41 | <AryehGregor> | Anyway, whatever. |
| 18:41 | <TabAtkins> | Developers is somewhat inaccurate for some people, though! I'm not a developer right now, frex. |
| 18:41 | <TabAtkins> | Whereas we're all engineering software to some degree. |
| 18:41 | <AryehGregor> | . . . kind of. |
| 18:42 | AryehGregor | votes that everyone's job title should be "Employee". |
| 18:42 | <TabAtkins> | Can I change my name to my SSN, too? |
| 18:42 | <mpt> | "SharedWorker" |
| 18:42 | <miketaylr> | i wanna be Señor Employee |
| 18:43 | <TabAtkins> | As we live in Amurrica, I will make it a point to call you *Mr.* Employee, miketaylr. |
| 18:43 | <AryehGregor> | TabAtkins, I'm pretty sure a judge wouldn't approve that. |
| 18:43 | <AryehGregor> | (the name change) |
| 18:44 | TabAtkins | has always lived in primarily Hispanic areas anyway. |
| 18:44 | <miketaylr> | same. |
| 18:45 | <AryehGregor> | Me too, I guess. |
| 18:45 | <AryehGregor> | Although I don't think of it that way, since among neighborhood people I practically only interact with the Jews. |
| 18:45 | <AryehGregor> | Although that's because I don't leave the house except when I have to go pray, to be fair. |
| 18:45 | <miketaylr> | hmm, now i'm in an predominantly arab, irish, and norwegian 'hood tho |
| 18:45 | <AryehGregor> | If it weren't for that, I'd spend weeks at a time without leaving my house, at least when I don't have school. |
| 18:46 | <TabAtkins> | Mountain View has a lot more asian varieties mixed in, but I'm still in a Hispanic area of town. Which a huge plus, because good hole-in-the-wall taquerias OMNOMNOMNOM |
| 18:47 | <miketaylr> | mmmm |
| 18:47 | <miketaylr> | that's #1 on my list when i head out for the SF jQuery conf. |
| 18:47 | <miketaylr> | burros |
| 18:51 | <TabAtkins> | When's the jQuery conf? |
| 18:51 | <miketaylr> | next weekend the 24th 25th |
| 18:52 | <miketaylr> | feel free to insert between 1 and 3 commas in that |
| 18:52 | <TabAtkins> | I choose a comma and "and" |
| 18:52 | <TabAtkins> | Any of you guys doing a dinner some night? |
| 18:53 | <miketaylr> | paul_irish would be the guy to ask, being the insider |
| 18:57 | <miketaylr> | they might be doing dinner onsite at the conf? dunno |
| 18:58 | <TabAtkins> | Yeah, I'll wait for him to come around and ask then. |
| 18:59 | hober | will be at the SFBA jQuery conf too |
| 19:00 | <miketaylr> | word up |
| 19:00 | <miketaylr> | i should like, write my talk |
| 19:01 | <paul_irish> | TabAtkins: sunday night we'll probably pull some folks together. i'll keep you in the loop (& hober too) |
| 19:01 | <TabAtkins> | Awesome. I'd like to meet you guys ftf. |
| 19:02 | <AryehGregor> | Whoa: http://to./ |
| 19:02 | <miketaylr> | totally |
| 19:02 | <AryehGregor> | A TLD URL shortener. |
| 19:02 | <AryehGregor> | You can only beat that if someone convinces ICANN to approve a one-letter TLD. :P |
| 19:02 | <AryehGregor> | Good PR on Tonga's part? |
| 19:03 | <TabAtkins> | I'm not sure how that works. It looks like the tld is the empty string. |
| 19:03 | <TabAtkins> | And the server name is just "to" |
| 19:03 | <AryehGregor> | Trailing dots in domain names are usually ignored. |
| 19:03 | <AryehGregor> | I'm not sure why it's required here. |
| 19:04 | <AryehGregor> | Observe: http://google.com./ |
| 19:04 | <AryehGregor> | The trailing dot is always present in the actual DNS request, I think. If you omit the dot, then the domain name is relative or something. |
| 19:04 | <AryehGregor> | I dunno, don't remember the details. |
| 19:04 | <AryehGregor> | Anyway, that's the .to TLD. |
| 19:04 | <TabAtkins> | Ok. |
| 19:06 | <hsivonen> | running a TLD is expensive. is there money in shorteners? |
| 19:06 | <jlebar> | Does HTML5 specify that we should ignore stylesheet <link>s which don't appear in the document's <head>? I can't find language one way or another. |
| 19:06 | <paul_irish> | twitter doesnt autolink the to./ shortened url's sadly. otherwise its the shortest shortener (though very close to tinyarro.ws) |
| 19:06 | <TabAtkins> | Depends. If you think people will abide by you showing a page while redirecting, you can do ads. Otherwise, you can sell usage info. |
| 19:07 | <othermaciej> | jlebar: I don't believe it requires ignoring them - I think it requires implementations to respect them |
| 19:07 | <othermaciej> | jlebar: however, it's nonconforming for content to have a stylesheet <link> outside the <head> section |
| 19:08 | <jlebar> | othermaciej, Thanks. |
| 19:18 | <hober> | paul_irish, miketaylr, TabAtkins: sounds good to me. |
| 19:42 | <zcorpan> | TabAtkins: let me know if MS says anything about video |
| 20:01 | <Hixie> | hober: yt? |
| 20:25 | <Hixie> | i find it amusing that some of the people who are most adament that we shouldn't violate the Atom spec's authoring requirements are the same people who argued that one option for HTML was to drop all authoring requirements |
| 20:34 | <othermaciej> | isn't that basically just Sam? (I don't think Julian ever suggested "drop all authoring requirements") |
| 21:52 | TabAtkins | keeps getting secret invites to beta tests for font things for some reason. |
| 21:55 | <TabAtkins> | Slightly related: FF's 3.6's font rendering on linux is occasionally extremely ugly. It's like, every once in a while, for no reason, they lose the ability to do sub-pixel stuff. |
| 21:56 | <TabAtkins> | So letters either gain odd extra-pixel spaces between them, or randomly switch between having 1 or 2px wide verticals, etc. |
| 22:01 | <paul_irish> | TabAtkins: ah you got that too? i would talk to you about it, but a checkbox i click seems to indicate that would be a faux pas.. |
| 22:01 | <paul_irish> | i'd dying for directwrite support to land in FF |
| 22:06 | <Hixie> | i give up on this atom thread. Neither Julian nor Sam are listening to a word I'm saying, both just keep repeating the same argument over and over despite my having explained why both their arguments are inapplicable. |
| 22:08 | <TabAtkins> | I'm not quite sure about Julian (he posts too much in that thread, so I've just sort of skimmed his arguments) but I think Sam is listening to you, but disagreeing in a different direction. |
| 22:09 | <TabAtkins> | I think you can interpret his words as agreeing with you on "there's a bug in the Atom spec". He'd probably say differently, but I believe the net effect of what he's saying is the same. |
| 22:17 | <hober> | Hixie: here |
| 22:24 | <Hixie> | hober: i replied to your mail |
| 22:24 | <Hixie> | TabAtkins: he keeps asking me to "test to see what happens when the IDs change" despite the fact that I'm not disagreeing with him on what happens if hte IDs change |
| 22:28 | <hober> | I think all Sam's trying to say with that is "feeds with shitty entry IDs and/or updated datetimes suck." Which, obviously, everyone knows so I don't know why he's banging on about that bit |
| 22:37 | <TabAtkins> | He's banging on about it because the HTML5 Atome extraction algo will, I think, generate shitty entry IDs (or no entry IDs? Similar problems exist.). |
| 22:40 | <othermaciej> | HTML5 doesn't require you to preserve the entry ID if you generate the feed multiple times |
| 22:41 | <othermaciej> | (or rather, it is a SHOULD rather than a MUST) |
| 22:41 | <othermaciej> | but it's not clear how much of that requirement is needed to avoid aggregators breaking |
| 22:41 | <Hixie> | we could change it to "MUST if possible" i guess |
| 22:41 | <TabAtkins> | Yeah, I see it now. |
| 22:41 | <othermaciej> | I suspect just requiring that the identical document sent through the same converter to generate identical atom:ids is both feasible and would mostly solve that particular problem |
| 22:41 | <TabAtkins> | Nod to othermaciej. |
| 22:42 | <othermaciej> | "MUST if possible" means "SHOULD"! |
| 22:42 | <Hixie> | i know |
| 22:42 | <Hixie> | that's why i wrote SHOULD |
| 22:42 | <Hixie> | but apparently that's not good enough for julian and sam |
| 22:42 | <hober> | Hixie: use "OUGHT TO" ( ref: http://edward.oconnor.cx/2006/02/more-rfc-2119-humor ) |
| 22:42 | <othermaciej> | I don't really understand the scope of the Atom spec's MUST |
| 22:42 | <TabAtkins> | It seems pretty easy to figure out how to generate a guurl from the article address and content. |
| 22:42 | <othermaciej> | when Julian has explained what he thinks it does and doesn't require, it sounds like he's making stuff up to suit his preferences rather than interpreting the Atom spec |
| 22:42 | <TabAtkins> | It is somewhat more difficult to generate one if the article changes between runs. |
| 22:43 | <TabAtkins> | Which I think they raised as a problem with it. |
| 22:43 | <othermaciej> | yeah, the only truly sound way to deal with "article changes between runs" is to require the HTML document to have unique IDs embedded |
| 22:43 | <hober> | othermaciej: FWIW, I thought your point re: "why the double standard between text->atom and html->atom" was spot-on |
| 22:44 | <othermaciej> | hober: I still don't feel like he gave a straight answer |
| 22:44 | <TabAtkins> | othermaciej: Right. So I think I'm fine with that. Changing the SHOULD to a MUST would still allow the ids to be different if the content changes between runs (it wont' be the "same input"). |
| 22:44 | <othermaciej> | but I also don't understand the double standard between "two runs of same converter" and "runs of different converters" |
| 22:45 | <othermaciej> | TabAtkins: it's not clear to me if Julian or Sam would be fine with that, or whether they would see that as violating the Atom spec (a possibly separate question) |
| 22:45 | <TabAtkins> | othermaciej: That one, at least, is similar to the distinction between "run on the same input" versus "run on similar input". |
| 22:45 | <othermaciej> | the problem is that the Atom requirement just doesn't make sense when starting from non-Atom input |
| 22:45 | <TabAtkins> | Right. |
| 22:45 | <othermaciej> | it's totally plausible to apply to systems that are already operating in Atom |
| 22:45 | <hober> | exactly |
| 22:45 | <TabAtkins> | Unless the content happens to also embed an appropriate guid. |
| 22:45 | <othermaciej> | but it's unimplementable if your input doesn't already have globally unique IDs embedded |
| 22:46 | <Hixie> | yup |
| 22:46 | <Hixie> | that's exactly the line of thought i went through when i wrote this stuff |
| 22:46 | <Hixie> | hence the should |
| 22:46 | <TabAtkins> | So, yeah, bug in the Atom spec. Change our spec to a MUST, and possibly explicitly call out the failing. |
| 22:46 | <othermaciej> | it *is* implementable for the special case of "same converter and identical content" |
| 22:47 | <TabAtkins> | It won't be a violation of our MUST if UAs generate new ids for altered content. |
| 22:47 | <Hixie> | one thing that's worth considering is whether we are interested in having a solution that outputs almost-valid atom that can be hand fixed to valid atom, or if we think the output must be valid atom |
| 22:48 | <TabAtkins> | The latter. Not much point in an automatic extraction algorithm if you still have to hand-edit the result. |
| 22:48 | <TabAtkins> | Since the producer won't be the one doing the extracting, the consumer will. |
| 22:50 | <hober> | Hixie: my first choice is that the algorithm do what it's doing now. html -> atom tools can (and should) help their users improve their HTML so that the results are valid |
| 22:50 | <hober> | my second choice, if the output must be valid Atom, is to drop entries that we can't come up with IDs from. that way the entries that do end up in the feed don't annoy the crap out of subscribers |
| 22:51 | <TabAtkins> | hober: For your first choice, does that resolve to the former or latter option in hixie's question? |
| 22:51 | <TabAtkins> | It sounds like the latter, unless you're seriously suggesting that feed readers should ask their users to correct the HTML of feed producers. |
| 22:51 | <hober> | TabAtkins: the former, though I wouldn't suggest that people hand-edit the atom |
| 22:52 | <TabAtkins> | Who is supposed to edit the Atom, then? At what point in the chain does it go from almost-valid to valid? |
| 22:52 | <hober> | I don't expect anybody to edit the Atom. |
| 22:53 | <hober> | I've got a site, and I decide to use an html2atom tool to make a feed from it |
| 22:53 | <hober> | I go to the tool, paste in my URL, and the result page is something like |
| 22:53 | <TabAtkins> | Then it never becomes valid, and you *can't* be agreeing with Hixie's former option. |
| 22:53 | <TabAtkins> | (Because that option, be definition, requires someone to edit the Atom at some point to make it valid.) |
| 22:53 | <hober> | "here's a url to an atom feed for your page. it doesn't look like it's valid; here are some ways you could improve your site so that your feed is more useful. have a nice day" |
| 22:54 | <hober> | or "here's a url... it's valid, congrats! here's a pat on the head" |
| 22:54 | <TabAtkins> | That's not the same use-case as "consume an HTML page as Atom". That's an HTML->Atom validator. |
| 22:55 | <hober> | no, it's a converter, that's providing lint-tool-esque advice when used |
| 22:55 | <hober> | the feed consumers just get the url to the (possibly invalid) atom feed |
| 22:55 | <TabAtkins> | It's allowed to flag things that aren't right. An actual conversion algo, though, either needs to output something valid, or we need to define exactly who turns it valid. |
| 22:55 | <hober> | it's the person feeding the site itno the converter that sees the lint/validation advice |
| 22:56 | <TabAtkins> | Okay, such a tool could work equally by only producing a valid feed, but also flagging things that it's skipped for invalidity. |
| 22:56 | <hober> | sure |
| 22:56 | <hober> | hence my compromise proposal to julian |
| 22:56 | <TabAtkins> | Then let's make sure that the algo just produces a valid feed. |
| 22:57 | <TabAtkins> | And let the market help people make their feeds better. |
| 22:57 | <hober> | sounds good to me |
| 23:12 | <JonathanNeal> | For any folks working on Microdata in here, it would be nice if I could put itemprop="fn org logo" on an <img /> with an alt. |
| 23:13 | <TabAtkins> | Hixie: ^^^ There really should be a way to get @alt in the property value. Automatically, preferably. |
| 23:14 | <TabAtkins> | JonathanNeal: You wouldn't be able to put it on the <img> directly, anyway - that just grabs the @src instead. But you *should* be able to put in on a <span> or <h1> or whatnot wrapping the <img>. |
| 23:14 | <JonathanNeal> | Yea that works too :) |
| 23:15 | <othermaciej> | TabAtkins: seems lame to add a span just to emit another property |
| 23:15 | <JonathanNeal> | I think in microformats you can place it on the <img /> itself. |
| 23:15 | <TabAtkins> | othermaciej: Shrug. Grabbing the @src of an <img> is useful. |
| 23:15 | JonathanNeal | pokes you for keeping up with the Jones'. |
| 23:16 | <othermaciej> | TabAtkins: I agree - and as just mentioned, grabbing the alt is also useful |
| 23:16 | <TabAtkins> | And so it should continue to be easy to do so. Using a wrapper is the obvious way to grab the alt without interfering with that. |
| 23:16 | <othermaciej> | I think it would be a design flaw if you had to add a superfluous DOM element just to emit both |
| 23:16 | <othermaciej> | although I do not have another design to propose |
| 23:16 | <TabAtkins> | You have to add wrappers for a lot of things in Microdata, if your data is part of prose. |
| 23:17 | <TabAtkins> | Though, with JonathanNeal's use-case, the <img> will commonly already have a wrapper <h1> to use. |
| 23:18 | <TabAtkins> | You either have to add wrapper, or add another level of indirection to specify where the property value comes from. The former seems a lot better to me, in this context.\ |
| 23:18 | <TabAtkins> | (If you asked me the same question in a CSS context, I'd say the opposite, because we love indirection.) |
| 23:23 | <othermaciej> | CSS WG must have a bunch of computer scientists in it |
| 23:23 | <TabAtkins> | Yes. |
| 23:25 | <Hixie> | when designing microdata i thought long and hard about how to get <img> to output one property for src="" and one for alt="" and i ended up deciding that was the mistake RDFa had made |
| 23:25 | <Hixie> | well, one of several, i guess |
| 23:27 | <TabAtkins> | Yeah, I don't think it should do it magically. But I think that <span itemprop=foo><img itemprop=bar src=baz alt=qux></span> should output foo:"qux", bar:"baz". |
| 23:27 | <TabAtkins> | Agreed that trying to stack the two together is a mistake in RDFa. |
| 23:28 | <TabAtkins> | Essentially just, whenever a property is using the text content of an element for its value, <img> should substitute in its @alt value. That's the whole point of @alt, after all - to be a textual equivalent of the image. |
| 23:31 | <othermaciej> | TabAtkins: in current Microdata, what would <span itemprop=foo><img src=baz alt=qux></span> emit? |
| 23:31 | <othermaciej> | (note lack of itemprop on the img itself) |
| 23:32 | <TabAtkins> | foo:"" |
| 23:33 | <TabAtkins> | Because @alt isn't part of the element's textContent. |
| 23:34 | <othermaciej> | would you propose changing what the markup I cited emits, or only in the case where the img element has an itemprop? |
| 23:34 | <othermaciej> | and what if there is more than just the <img> element inside the span? |
| 23:35 | <othermaciej> | additional side note: is there a way to get the contents of a "title" attribute into a Microdata property? |
| 23:35 | <TabAtkins> | I would propose changing what the markup you cited emits. It should emit foo:"qux". |
| 23:35 | <othermaciej> | those are the two cases I can think of where useful text is likely to be an attribute value instead of text content |
| 23:36 | <TabAtkins> | In the case of <span itemprop=foo>foo <img alt=bar> baz</span>, it should emit foo:"foo bar baz". |
| 23:36 | <othermaciej> | TabAtkins: that is a self-consistent model |
| 23:36 | <TabAtkins> | There is no way to get @title into a Microdata value. |
| 23:36 | <othermaciej> | although that solution doesn't scale to @title |
| 23:37 | <Hixie> | TabAtkins: yeah i've long been a fan of inventing some property that serialises HTML to text "correctly", e.g. turning <bdo> into unicode bidi formatting characters, inserting quotes for <q>, inserting newlines for <br>, etc. People haven't really been enthusiastic about it. |
| 23:37 | <TabAtkins> | @title isn't a textual equivalent of the element, so it shouldn't substitute itself normally. |
| 23:37 | <othermaciej> | Hixie: WebKit tries to do that for innerText |
| 23:37 | <Hixie> | TabAtkins: in practice btw there are actually few cases where you want the alt="" -- mostly you're grabbing the URL for purposes other than showing it in a context where you need the alt, e.g. you're grabbing it to label that image with metadata like a license |
| 23:37 | <Hixie> | othermaciej: really? |
| 23:38 | <TabAtkins> | And, unfortunately, it doesn't share the distinction of @src, @href, etc of being a special, use-restricted attribute so that you can usefully say "whenever @itemprop is <foo>, use @bar for the value". |
| 23:38 | <othermaciej> | TabAtkins: right - it's clearly ancillary information that shouldn't inject itself into the text content |
| 23:38 | <othermaciej> | Hixie: well at the very least we respect <br> and omit the text for some elements that are always unrendered |
| 23:38 | <othermaciej> | can't remember if we insert generated content |
| 23:38 | <othermaciej> | but innerText at least at one point did the same thing as Copy --> Past as Plain Text |
| 23:38 | <othermaciej> | *Paste |
| 23:39 | <Hixie> | interesting |
| 23:39 | <TabAtkins> | Hixie: I agree that the case of wanting *only* the @alt, as in <img itemprop=foo alt=bar>, are rare. I don't care about that. I would like that case to continue to emit the @src. |
| 23:39 | <Hixie> | TabAtkins: i'm not talking about wanting only the alt, i mean wanting both |
| 23:39 | <TabAtkins> | But the cases on pages that I write where I have <h1><img alt="My Company Name"></h1> are much more common. |
| 23:40 | <JonathanNeal> | Yes, that's common. |
| 23:40 | <TabAtkins> | I'm not sure what you're objecting to changing, Hixie? |
| 23:40 | <Hixie> | the algorithm to grab text for a property |
| 23:40 | <TabAtkins> | If you want both, you specify an @itemprop on both the <img> (for the @src) and a wrapper (for the @alt). |
| 23:41 | <Hixie> | just use <meta> |
| 23:41 | <TabAtkins> | That's ridiculous when the information is *right there*, and it's completely unambiguous which data you want. |
| 23:41 | <Hixie> | *shrug* |
| 23:42 | <Hixie> | it's a pretty rare case and would make the mechanism less intuitive |
| 23:42 | <TabAtkins> | It's silly that <span itemprop=foo>foo <img alt=bar> baz</span> doesn't emit foo:"foo bar baz", and the only way to make it do so is to duplicate the whole text value in the <meta> |
| 23:42 | <TabAtkins> | ...no, it's much more intuitive. @alt is the textual replacement for the image. If you want the text of an element that contains an image, you'll get the textual replacement of it. |
| 23:43 | <TabAtkins> | This is basic a11y stuff, and is the whole reason that @alt exists. |
| 23:43 | <Hixie> | it's also "silly" that <span itemprop=foo> <q>test</q> <br> <bdo dir=rtl>abc</bdo> </span> doesn't emit quotes, a newline, and bidi formatting characters |
| 23:43 | <TabAtkins> | Agreed, to be honest. Let's make all those changes. |
| 23:44 | <Hixie> | doing that leads to the implementation of microdata doubling or tripling in size |
| 23:44 | <Hixie> | it's not a good tradeoff |
| 23:45 | <Hixie> | and frankly it isn't necessary for most uses of microdata |
| 23:45 | <TabAtkins> | Let's make browsers include a property for emitting it. |
| 23:45 | <Hixie> | browsers aren't the main consumers |
| 23:47 | <TabAtkins> | Microdata currently defines that case as being the value of textContent. This is a property exposed by whatever DOM implementation you're using. We'd define a new property for DOM implementations to support that does "smart" text content. |
| 23:48 | <TabAtkins> | If you're not relying on an external parser to create and handle the DOM, then adding "smart" text content handling is *definitely* not a "doubling or tripling" of your code size. |
| 23:49 | <Hixie> | you'd be surprised |
| 23:49 | <Hixie> | textContent is implementable in about 3 lines |
| 23:49 | <Hixie> | what we're talking about here basically means implementing an HTML renderer for plain text |
| 23:49 | <Hixie> | that's 100+ lines |
| 23:49 | <Hixie> | maybe far more |
| 23:50 | <TabAtkins> | A "renderer" that handles, what, four cases total? Plain text, <q> text, bidi text, and @alt. |
| 23:50 | <JonathanNeal> | All I want is alt :) |
| 23:50 | <TabAtkins> | If you're starting from a SAX parser or something, it's definitely not 100+ lines unless you really, really suck somehow. |
| 23:51 | <Hixie> | there's far more to HTML than just the cases I mentioned |
| 23:53 | <ment> | how to best benchmark how much time browser spends rematching css on dom tree when i change the dom tree using js? |
| 23:54 | <TabAtkins> | Let's see... I can see the possibility that you might want to do <sub> and <sup>, but I don't think there's an accept way to render them in plaintext. You could *maybe* argue that <em> and <strong> deserve special formatting, but I can reasonably argue against it, I think. I believe that's about it. |
| 23:55 | <TabAtkins> | Everything else is sufficient as plain text for any purpose that Microdata might need. |
| 23:55 | <Hixie> | i am highly skeptical |
| 23:55 | <Hixie> | and again, i really don't think the use cases need this |
| 23:55 | <TabAtkins> | I think that @alt is the highest-priority one. |
| 23:56 | <TabAtkins> | If you're rolling your own DOM, then just where you loop through the nodes and check if they're text nodes, also check if they're element nodes with the name "img". |
| 23:56 | <TabAtkins> | That is 2 lines (possibly more depending on your code formatting guidelines). |
| 23:57 | <TabAtkins> | You're already having to check if a node is an element node, to know if you have to recurse into it to search for more text nodes. |
| 23:58 | <JonathanNeal> | All I want is alt :) |
| 23:58 | <TabAtkins> | So I challenge your statement that this would greatly increase the implementation cost. The increase is so minor as to be trivial. |
| 23:58 | <TabAtkins> | JonathanNeal: I'm fine with just @alt too. ^_^ |
| 23:59 | <TabAtkins> | At least with <q> and <bdo> the contents are *available*, even if formatted badly. <img alt> is simply *omitted* as it stands. |