| 07:47 | <zcorpan> | hsivonen: you sure we want DOMParser to parse noscript as markup? |
| 07:58 | <annevk> | I think that's what happens for XMLHttpRequest too |
| 07:59 | <zcorpan> | oh |
| 07:59 | <annevk> | but maybe they should all use the same mode as innerHTML? |
| 07:59 | <zcorpan> | for some reason i thought xhr parsed with "scripting enabled" but without running scripts |
| 08:00 | <zcorpan> | if xhr is interoperable, then it seems fine |
| 08:47 | <annevk> | instead of // historical maybe DOM4 should use // legacy |
| 08:47 | <annevk> | hmm |
| 08:48 | <annevk> | basically we need one word that means, existed once, no longer implemented and one word that means, still there, but do not use |
| 08:49 | <jgraham> | The word for the latter is "deprecated: "p |
| 08:49 | <annevk> | but deprecated is so misunderstood |
| 08:49 | <annevk> | hmm |
| 08:51 | <jgraham> | The word, or the concept? |
| 09:17 | <mpt> | I think that's the oldest topic I've ever seen in an IRC channel |
| 09:59 | <hsivonen> | Ms2ger: congrats for Accept-Charset removal making it to a release finally. |
| 10:01 | <Ms2ger> | Did it? That's good to hear :) |
| 10:03 | <hsivonen> | Ms2ger: Yahoo! still hasn't fixed Babelfish |
| 10:04 | <hsivonen> | I'm unsurprised |
| 10:04 | <Ms2ger> | Go Yahoo! |
| 10:13 | <zcorpan> | how to resolve conflicts in svn that works every time: remove working copy, do a new checkout |
| 10:14 | <jgraham> | For small values of "resolve" |
| 10:16 | <Ms2ger> | svn di > foo && patch -R <foo? |
| 10:28 | <hsivonen> | aargh. how can I type "since" as "sense"? I wasn't even using voice recognition. |
| 10:28 | hsivonen | hangs head in shame |
| 10:30 | <zcorpan> | you could claim to use dvorak where e and i only have one key in between |
| 10:36 | <hsivonen> | zcorpan: I did type it on dvorak, but the explation is still implausible |
| 10:39 | <michel_v> | implausible indeed, there's a u in the middle :p |
| 10:53 | <hsivonen> | zcorpan: regarding noscript in DOMParser: It's consistent with XHR and it's logical, since neither DOMParser nor XHR runs scripts |
| 10:54 | <hsivonen> | zcorpan: people who control the input and don't want noscript, should probably not put noscript in the input |
| 10:57 | <hsivonen> | implementing features and fixing bugs interferes with my ability to track public-html |
| 11:01 | <zcorpan> | hsivonen: consistent with xhr is good |
| 11:02 | <hsivonen> | so it looks like public-html is as full of a11y Revert Requests as ever :-( |
| 11:11 | <jgraham> | Yeah, it turns out that public-html is the first against the wall when there's work to get done |
| 11:13 | <hsivonen> | What kind of product does Charles Pritchard work on? |
| 11:39 | <mhausenblas> | hsivonen around? |
| 11:41 | <hsivonen> | mhausenblas: yes. Thanks for editing Wikipedia. |
| 11:41 | <mhausenblas> | yw |
| 11:42 | <mhausenblas> | lemme know if there's something else to be fixed over there ;) |
| 11:44 | <hsivonen> | hmm. the second sentence still describes the old XHR instead of the new generic thing for loading URL-addressable resources |
| 11:46 | <hsivonen> | curiously, Wikipedians don't seem to have a problem with using primary sources for fact citations when the primary sources are W3C specs |
| 11:47 | <mhausenblas> | yup ;) |
| 11:48 | <mhausenblas> | now, happy to edit more there, but would need some concrete wording - just paste it here or vial mail to michael DOT hausenblas AT gmail DOT com ... ok, hsivonen? |
| 11:51 | <hsivonen> | I'd say something like "XMLHttpRequest is a API for loading URL-addressable resources and for sending data to URL end points from scripts." |
| 11:57 | <mhausenblas> | ok, hsivonen - but where? :) |
| 11:57 | <mhausenblas> | replacing the first sentence? |
| 12:00 | <hsivonen> | mhausenblas: I meant the second, but I guess what covers part of the first one, too |
| 12:01 | <mhausenblas> | so, s/It is used to send HTTP or HTTPS requests directly to a web server and load the server response data directly back into the script./XMLHttpRequest is a API for loading URL-addressable resources and for sending data to URL end points from scripts |
| 12:01 | <mhausenblas> | ? |
| 12:01 | <mhausenblas> | hmm |
| 12:02 | <mhausenblas> | I think it better replaces the first sentence, but your call really ;) |
| 12:12 | <hsivonen> | mhausenblas: hmm. maybe it replaces the first sentence if the second is the qualified by "It is most commonly used..." or something. |
| 12:21 | <annevk> | http://hsivonen.iki.fi/accept-charset/ is nice |
| 12:21 | <annevk> | I wish we killed the Accept header too when there was still a chance of doing that |
| 12:21 | <annevk> | i.e. that our predecessors killed it |
| 12:24 | <hsivonen> | annevk: I now wish Accept had been killed. Instead what really happened a decade ago was that I advocated bloating Accept. :-( |
| 12:25 | <annevk> | good point, I might have done the same |
| 12:27 | <zcorpan> | Accept: */* works for most requests, doesn't it? |
| 12:27 | <annevk> | yeah, that's what I'm advocating now |
| 12:28 | <annevk> | although our network guys claim it breaks some stuff |
| 12:28 | <annevk> | I haven't really followed up |
| 12:28 | <hsivonen> | annevk: what breaks? X-Philes blogs? |
| 12:28 | <annevk> | not sure |
| 12:28 | <hsivonen> | which reminds me that I should make an HTML5 version of my master's thesis and zap conneg |
| 12:30 | <annevk> | hmm |
| 12:30 | <annevk> | more people added me on G+ than Twitter |
| 12:30 | <annevk> | seems suspicious |
| 12:32 | <annevk> | anyone here going to Prague this weekend btw? |
| 12:44 | <Lachy> | hsivonen, in what ways did you previously advocate bloating Accept? |
| 12:45 | <annevk> | I think I have suggested that application/mathml+xml needed to be added |
| 12:45 | <annevk> | somewhere |
| 12:47 | <Lachy> | looks like they ended up adding that, along with 2 others http://www.w3.org/TR/MathML3/appendixb.html |
| 12:49 | <annevk> | I wonder if HTTP covers stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=613159#c14 |
| 12:49 | <hsivonen> | Lachy: putting application/xhtml+xml in the Accept header |
| 12:49 | <Lachy> | oh |
| 12:51 | <hsivonen> | Lachy: https://bugzilla.mozilla.org/show_bug.cgi?id=58040#c28 |
| 12:53 | <zcorpan> | made sense with the landscape as it was then |
| 12:57 | <annevk> | ooh man |
| 12:57 | <annevk> | people knew back in 2000 |
| 12:57 | <annevk> | comment 0 |
| 12:57 | <annevk> | "Comment in the source code says that the Accept: */* header is done because MIME based content negotiation is dead." |
| 12:59 | <hsivonen> | other fun threads: http://groups.google.com/group/netscape.public.mozilla.mathml/browse_thread/thread/f0d7442075946397/ |
| 12:59 | <hsivonen> | http://groups.google.com/group/netscape.public.mozilla.mathml/browse_thread/thread/ab83de837ff21576/ |
| 12:59 | <hsivonen> | http://groups.google.com/group/netscape.public.mozilla.mathml/browse_thread/thread/a2dd34dc398590f2/ |
| 13:00 | <hsivonen> | annevk: still dead, with more bytes wasted. :-( |
| 13:05 | <jgraham> | hsivonen: People are claiming that Chrome still send Accept-Charset |
| 13:07 | <hsivonen> | jgraham: whoa. indeed. Turns out that I tested something else that was charset-related in my Chrome window today but not *this* and thought I had tested this |
| 13:15 | <Ms2ger> | Fun stuff, webkit inventing proprietary stuff and filing a bug on Gecko to implement it without bothering to bring it up on spec lists |
| 13:15 | <Ms2ger> | https://bugzilla.mozilla.org/show_bug.cgi?id=403510 |
| 13:17 | <jgraham> | Wow |
| 13:17 | <TabAtkins_> | son of a *bitch* |
| 13:18 | <Ms2ger> | Young dog? |
| 13:19 | <jgraham> | Oh, I thought that was TabAtkins_'s password |
| 13:19 | <TabAtkins_> | Nah, man, that's hunter42 |
| 13:19 | <hsivonen> | jgraham: thanks. I added a correction to the post. Makes the situation less newsworthy. :-( |
| 13:19 | <Ms2ger> | hunter2* |
| 13:20 | <TabAtkins_> | d'oh. |
| 13:20 | <TabAtkins_> | I ruined the joke. |
| 13:20 | <Ms2ger> | Sorry :) |
| 13:24 | <TabAtkins_> | Aw man, and it's Arv that filed it. In three hours I'll bitch him out. |
| 13:25 | <hsivonen> | argh. my bogus article made it to hacker news already. :-( |
| 13:25 | <MikeSmith> | hsivonen: bogus article? |
| 13:26 | <MikeSmith> | hsivonen: btw, hsivonen: http://www.jumis.com/software/developer.html lists some Charles Pritchard software |
| 13:28 | <Ms2ger> | annevk, any particular reason you dropped Abstract from the DOM4 ED? It seems somewhat useful |
| 13:34 | <hsivonen> | MikeSmith: the bogus article being http://hsivonen.iki.fi/accept-charset/ |
| 13:42 | <hsivonen> | MikeSmith: so Charles Pritchard specializes in implementing the canvas API in contexts other than browser-native implementations? |
| 13:42 | <hsivonen> | I wonder what the motivating use cases are |
| 13:43 | <hsivonen> | jgraham: I'm amused by this reply to a comment of yours: http://news.ycombinator.com/item?id=3557299 |
| 14:05 | <Ms2ger> | MikeSmith, seems like the CSSOM bug component should move from WebAppsWG to CSS |
| 14:06 | <Ms2ger> | (I can file a bug) |
| 14:06 | <MikeSmith> | OK |
| 14:06 | <MikeSmith> | yeah please |
| 14:06 | <Ms2ger> | And Fullscreen to webapps now we have consensus? |
| 14:06 | <MikeSmith> | if we actually do |
| 14:07 | <Ms2ger> | OH, hmm |
| 14:07 | <Ms2ger> | The Bugzilla product only has an a11y component, where should I file? |
| 14:08 | <Ms2ger> | MikeSmith, ^ |
| 14:10 | <annevk> | per http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0542.html it will be added to the draft charter |
| 14:11 | <annevk> | but maybe we should wait until it is actually chartered |
| 14:13 | <Ms2ger> | wfm |
| 14:18 | <Ms2ger> | annevk, is there anything besides document.{documentURI,URL} to test for concept-document-url? |
| 14:19 | <annevk> | I think window.location is a different URL |
| 14:19 | <annevk> | "current URL" |
| 14:19 | <annevk> | you could test xml:base stuff |
| 14:19 | <annevk> | maybe |
| 14:24 | <matjas> | hsivonen: I couldn’t find a Chrome bug for Accept-Charset, so I created a simple test case (http://mathiasbynens.be/demo/accept-charset) and filed a ticket: http://crbug.com/112805 |
| 14:25 | <Ms2ger> | Anybody around with IE? |
| 14:26 | <annevk> | I can fire it up |
| 14:26 | <matjas> | hsivonen: make that http://crbug.com/112804; I was 23 seconds too late to file it |
| 14:26 | <Ms2ger> | download link on livedom, if that works in IE |
| 14:27 | <annevk> | sorry |
| 14:28 | <annevk> | VMWare trial expired |
| 14:28 | <annevk> | have to figure out how to get license key first (if Opera has some bulk license or not) |
| 14:33 | <Philip`> | annevk: Can you use the free VMware Player? |
| 14:34 | <Ms2ger> | Ta anyway |
| 14:34 | <hsivonen> | matjas: thanks |
| 14:35 | <annevk> | figured out how, will take some time :( |
| 14:37 | <Ms2ger> | People may be interested in www.cs.purdue.edu/homes/jv/pubs/ecoop11.pdf "The Eval that Men Do: A Large-scale Study of the Use of Eval in JavaScript Applications" |
| 14:48 | <annevk> | http://www.reddit.com/r/pics/comments/pczpz/this_guy_was_elected_president_of_finland/ haha |
| 14:56 | <hsivonen> | annevk: what's the "haha" part? |
| 14:58 | <Ms2ger> | Fins |
| 14:58 | <Ms2ger> | ;) |
| 15:00 | <annevk> | hsivonen: just kind of funny that the president does that kind of thing |
| 15:00 | <annevk> | in jeans |
| 15:03 | <krijnh> | Somebody from #css: just has a power failure here, during your meeting. If somebody can mail me the missing parts, I'll add them |
| 15:03 | <Ms2ger> | TabAtkins, ^ |
| 15:04 | <hsivonen> | annevk: it means he is an elitist who has a house with a yard instead of living in a block of flats :-) |
| 15:04 | <Ms2ger> | Hah |
| 15:06 | jgraham | doesn't really understand why flats are so popular in Scandanavia |
| 15:06 | <hsivonen> | jgraham: they are more energy-efficient and you don't need to take care of the snow yourself |
| 15:06 | <Ms2ger> | What he said |
| 15:07 | <jgraham> | Well they might be more environmentally friendly |
| 15:07 | <jgraham> | But actually living in them sucks |
| 15:07 | <hsivonen> | jgraham: how? |
| 15:08 | <jgraham> | No outdoor space. Horrible communal areas (satircases, etc).People on all sides -> high chance of noise. Typically communal facilities that have to be booked. Landlords. |
| 15:08 | <TabAtkins_> | krijnh: I'm on it. |
| 15:09 | <TabAtkins_> | krijnh: I'm not sure what the outage was, and I don't want to diff these myself. |
| 15:09 | <TabAtkins_> | s/what/when/ |
| 15:11 | <hsivonen> | jgraham: you don't have a landlord if you own stock in the apartment building LLC |
| 15:12 | <jgraham> | Right, that would be a bostadsrätt in Swedish. All the other points apply though. |
| 15:13 | <hsivonen> | jgraham: I don't feel a need for non-shared yard. The staircase is clean enough. |
| 15:14 | <hsivonen> | jgraham: also, I'm not that into sauna, so I don't need to book sauna facilities, since I don't use them |
| 15:14 | <hsivonen> | jgraham: besides, many apartments have per-apartment saunas, but that's again energy-inefficient |
| 15:15 | <jgraham> | I was thinking of washing machines :) Of course it is possible to have your own but the default here is shared washing facilities |
| 15:15 | <jgraham> | And most people stick with the default it seems |
| 15:16 | <timeless> | smaug____: i'm not actively working on bugzilla. and lpsolit hasn't been a very welcoming person. i do not have the energy to deal with him or his cabal |
| 15:17 | karlcow | loves shared washing machines! |
| 15:17 | <jgraham> | karlcow: That needs an explaination or a <sarcasm> sign for the hard of understanding |
| 15:18 | <karlcow> | not sarcasm. |
| 15:19 | <karlcow> | I do not own a washing machine for the last 10 years and I find that a lot better as a society in urban environment. We go usually to the laundry beside our place. 1 min walking. Winter or summer. |
| 15:20 | <karlcow> | When I was living in Japan, I didn't have a fridge because I was living very close from supermarket opened at convenient time. So the fridge was the supermarket. Not possible unfortunately where I am now. |
| 15:20 | <karlcow> | I ditched the car 12 years ago too aka sold it. |
| 15:20 | <karlcow> | and TV |
| 15:21 | <hsivonen> | karlcow: you always ate full packs of perishable groceries? |
| 15:22 | <jgraham> | karlcow: Now you are turning into area man |
| 15:22 | <karlcow> | hsivonen: in Japan you can buy in small portion :) that is the key. |
| 15:22 | <jgraham> | karlcow: But the assertion that not having a washing machine was better for the environment is [citation needed] |
| 15:23 | <jgraham> | It isn't trivially obvious to me why comercial machines would be more efficient |
| 15:23 | <jgraham> | Unless it is the machine itself that you are thinking of |
| 15:24 | <karlcow> | plenty of individual washing machines used once or twice a week compared to a washing machine used a lot more by many people is definitely better for the environment. |
| 15:24 | <jgraham> | But I would have thought the machine lifetime was ~number of uses rather than ~ time |
| 15:24 | <karlcow> | yup the machine. |
| 15:24 | <jgraham> | karlcow: That is far from obvious |
| 15:25 | <karlcow> | jgraham: do you have used the same machine for 10 years |
| 15:26 | <jgraham> | karlcow: Well not right now since we just moved and got the machine that the old people had bought (I think it is like ~5 years old). But my parents have, for example. |
| 15:27 | <annevk> | Ms2ger: in particular, DOM made those attributes non-nullable |
| 15:27 | <Ms2ger> | Yeah |
| 15:27 | <Ms2ger> | That's not an argument, though ;) |
| 15:30 | <annevk> | not sure why browsers are so woefully inconsistent for DOMParser |
| 15:31 | <annevk> | e.g. why it's different from createDocument in Gecko for instance |
| 15:33 | <Ms2ger> | No idea |
| 15:44 | <hsivonen> | so does HTML+RDFa 1.1 really want to add href and src to all elements? |
| 15:44 | <hsivonen> | see http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax |
| 15:44 | <hsivonen> | says All RDFa attributes and valid values (including CURIEs), as listed in Section 2.1: The RDFa Attributes, must be allowed and seen as conforming when used in an HTML4, HTML5 or XHTML5 document. |
| 15:45 | <hsivonen> | http://www.w3.org/TR/rdfa-core/#rdfa-attributes doesn't really define "RDFa attributes" |
| 15:45 | <hsivonen> | but points to an appendix "For a complete list of RDFa attribute names and syntax, see Attributes and Syntax." |
| 15:45 | <timeless> | awesome |
| 15:46 | <hsivonen> | the appendix being http://www.w3.org/TR/rdfa-core/#s_syntax |
| 15:46 | <hsivonen> | which lists href and src |
| 15:46 | <hsivonen> | I have trouble figuring out which kind of bad spec writing this is |
| 15:47 | <hsivonen> | oops. it's not an appendix |
| 15:47 | <hsivonen> | just a plain section |
| 15:49 | <hsivonen> | whoa. http://www.w3.org/TR/rdfa-in-html/ contains a DTD |
| 15:49 | <annevk> | hahaha |
| 15:50 | <hsivonen> | a quick look suggests the DTD puts href on all elements but doesn't put src on all elements |
| 15:52 | <manu1> | hsivonen - I don't think we intended @src to go on all attributes, only @href. |
| 15:53 | <manu1> | not that people tend to use @href on all attributes... it may be used so little that we could deprecate it's usage if an RDFa 2.0 ever ends up being created (I have no intention of being a part of that) |
| 15:54 | <manu1> | hsivonen - somewhat related: Searching for Microformats, RDFa, and Microdata Usage in the Wild - http://manu.sporny.org/2012/structured-data-searching/ |
| 15:56 | <manu1> | also, the latest Editor's draft moves the DTD out of the spec: http://dev.w3.org/html5/rdfa/ |
| 15:56 | <manu1> | if you have suggestions on how to improve any of those documents, we'd love to hear about it on public-rdfa-wg⊙wo |
| 15:57 | <hsivonen> | manu1: oops. I fell into the old trap of reading stuff under /TR/. :-( I should know better. |
| 15:57 | <manu1> | yep - we need a warning across all W3C non-REC TR docs... wonder when that'll happen. |
| 15:59 | <hsivonen> | manu1: is there an ED of RDFa Core, too? |
| 16:01 | <manu1> | the TR version is the latest for RDFa Core |
| 16:01 | <manu1> | we're in LC for that doc |
| 16:02 | <hsivonen> | manu1: ok |
| 16:06 | <hsivonen> | manu1: I filed a bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=15913 |
| 16:06 | manu1 | looks. |
| 16:10 | <manu1> | Thanks for the bug report. I have a feeling that the RDFa WG is going to keep @href, @rel and @rev allowable on all attributes (it was a big debate during the RDFa 1.0 days and we had revisted the decision multiple times and kept allowing them on all attributes. You also can't do some forms of chaining w/o them, and because it would break backwards compatibility w/ XHTML, and if we have... |
| 16:10 | <manu1> | ...different rules for different host languages it's going to confuse authors). I think allowing @src on everything was a mistake, but we'll check to make sure that's the case. |
| 16:11 | <manu1> | ... and that's not to say that the HTML WG will come to the same conclusion, just giving you a heads up on what I predict will happen. |
| 16:12 | <manu1> | hsivonen, what would be more compelling, imho, is some sort of technical issue raised by the modification... Does adding @href to span's create some sort of nastiness in the DOM/parsers/etc.? |
| 16:14 | <manu1> | That said, with the current RDFa Lite 1.1 changes, it may be that the vast majority of markup doesn't end up using @rel and @rev... and the markup that does use @href may limit itself to <a> - another suggestion that you might put in there is to have us tell authors that they should strive to only use @href where it is typically found in "regular" HTML (even though I know that's not your... |
| 16:14 | <manu1> | ...ideal solution) |
| 16:15 | <annevk> | you keep saying attributes when you mean elements |
| 16:16 | <annevk> | fwiw ^^ |
| 16:16 | <manu1> | yeah, sorry - I keep doing that :) |
| 16:16 | <manu1> | s/@href, @rel and @rev allowable on all attributes/@href, @rel and @rev allowable on all elements/ ... etc. |
| 16:17 | <annevk> | that sounds rather silly given it was vetoed by implementors time and again |
| 16:18 | <Ms2ger> | Does Opera still implement global href? |
| 16:18 | <annevk> | but who knows, maybe the crazy happens one day |
| 16:18 | <annevk> | Ms2ger: did we ever? |
| 16:18 | <Ms2ger> | Through CSS |
| 16:18 | <annevk> | I think we killed those |
| 16:18 | <annevk> | stopped working at some point |
| 16:19 | <hsivonen> | manu1: the argument is that <p href="http://example.org">Click?</p>; looks like a link that can be clicked to follow but isn't |
| 16:19 | <hsivonen> | manu1: and <p src="http://example.org/foo"></p>; looks like emdedding some content but isn't |
| 16:19 | <manu1> | hsivonen, yes - I understand the argument... but we've found that RDFa authors don't always want to create click-able links. |
| 16:19 | <manu1> | your second example shouldn't be allowed, btw |
| 16:20 | <manu1> | (and @href is more familiar to them than @resource) |
| 16:21 | <manu1> | annevk, re: "vetoed by implementors" - do you mean in HTML or in RDFa? |
| 16:21 | <annevk> | former |
| 16:21 | manu1 | nods at annevk. |
| 16:22 | <annevk> | and if you want <p href> to mean something else than the proposed <p href> from XHTML 2.0... |
| 16:22 | <manu1> | hsivonen, like I said - it's not best practice, we don't suggest that people do it... but at times, they don't want a clickable link... and they typically put this stuff on <span> and <div>s |
| 16:22 | <annevk> | well that sounds like a world of confusion |
| 16:22 | <manu1> | XHTML 2.0-what? |
| 16:22 | <annevk> | and prevents extending HTML in such a way in the future |
| 16:23 | <manu1> | are there plans to extend HTML to allow @href on all elements? |
| 16:23 | <hsivonen> | manu1: don't you have @resource already for non-clickable stuff? |
| 16:23 | <annevk> | there's certainly demand, not so much plans at this point |
| 16:23 | <annevk> | and @about |
| 16:24 | <manu1> | hsivonen - we have @resource to overload @href if used on the same element... not necessarily for non-clickable stuff. |
| 16:24 | <manu1> | annevk - there are plans to add @about to HTML? |
| 16:24 | <manu1> | or rather, demand? |
| 16:25 | <hsivonen> | manu1: when you use both @href and @resource, can anyone except RDFa WG members remember what triples it produces? |
| 16:25 | <manu1> | If there is demand to add @href to HTML... is it being introduced in HTML+RDFa in an incompatible way to that demand, annevk? |
| 16:26 | <manu1> | hsivonen: The question is moot - do people understand how the DOM is built if elements are placed where they shouldn't be? |
| 16:26 | <hsivonen> | manu1: as for nastiness for DOM/parsers/etc., I expect someone will make the argument that <p href> should become a clickable link, since RDFa "allowed" it but it doesn't "work" |
| 16:26 | <manu1> | The solution in both cases is the same: You use a browser to check to see if the page "looks right"... you use an RDFa processor to see if the page produces the correct triples. |
| 16:26 | <hsivonen> | manu1: you guys are making the incomprehensible stuff conforming |
| 16:27 | <manu1> | That is, there are exceptions to all rules, especially when it comes to what authors intend and what ends up happening in the browser. |
| 16:27 | <hsivonen> | manu1: HTML makes markup that triggens the incomprehensible fixups non-conforming |
| 16:28 | <manu1> | hsivonen: If someone makes the argument that <p href> should become a clickable link, they will also need to convince everybody that the entire paragraph should have a bright blue underline (or some other visual cue to specify it is a clickable link) and at that point, their argument will be dismissed. |
| 16:28 | <manu1> | hsivonen: define "incomprehensible fixups" |
| 16:29 | <Ms2ger> | <table>Foo</table>, perhaps? |
| 16:29 | <hsivonen> | manu1: in the HTML case, stuff like the AAA |
| 16:30 | <annevk> | Ms2ger: did you define the origin of the Document? |
| 16:30 | <Ms2ger> | No |
| 16:31 | <annevk> | Ms2ger: that also needs to be covered I believe |
| 16:31 | <Ms2ger> | I guess it does |
| 16:31 | <Ms2ger> | I'll need prose for that, though, because I don't understand origin stuff :) |
| 16:31 | <manu1> | hsivonen, so what is "incomprehensible" in your opinion? Please don't say 'everything' that is not currently defined in HTML but is in RDFa because I can't work with that... :) |
| 16:32 | <manu1> | hsivonen - stuff like this: <table href="...">Foo</table> ? |
| 16:33 | <manu1> | or stuff like this: <span href="...">My homepage</span> ? |
| 16:33 | <manu1> | (if the second one is incomprehensible... why is it incomprehensible)? |
| 16:34 | <annevk> | Ms2ger: filed a bug for now |
| 16:34 | <hsivonen> | manu1: 'incomprehensible stuff includes <table><i><b><font><font><font><font></b></font></i></table> |
| 16:34 | <annevk> | Ms2ger: might figure out the answer later |
| 16:34 | <Ms2ger> | Thanks |
| 16:34 | <manu1> | I agree that the first one is incomprehensible, but how could anybody do that that doesn't cause the browser manufacturers to say: "Wow, that markup is really stupid, we're not going to support it." |
| 16:34 | <annevk> | maybe document-origin should be part of DOM too... hmm |
| 16:35 | <hsivonen> | manu1: also <span resource="http://example.com/a"; src="http://example.com/b"; about="http://example.com/c"; property="http://example.com/d"; src="http://example.com/e">; |
| 16:35 | <manu1> | hsivonen: Ok, yes <table><i><b><font><font><font><font></b></font></i></table> is ridiculous - but how does that apply to @href everywhere... seems like an extreme off-base example to prove a point? Is <p href="..."> a better representation of your concern? |
| 16:36 | <manu1> | and is that concern making <p> a click-able link... or the ability to express that "this paragraph has a hyperlink pointing to X"? |
| 16:36 | <hsivonen> | manu1: <table><i><b><font><font><font><font></b></font></i></table> is non-conforming. You are making <p href> conforming. |
| 16:36 | <manu1> | or is the concern that @href may end up on <p> eventually and we're spec'ing it in a way in HTML+RDFa that makes it impossible to have HTML adopt @href in the future? |
| 16:37 | <hsivonen> | manu1: the concern is making stuff that doesn't do what it looks like conforming |
| 16:37 | <manu1> | hsivonen: Yes, but why is <p href> conforming such a terrible thing? (other than it's just bad practice)? |
| 16:37 | <Ms2ger> | Because it doesn't work |
| 16:37 | <hsivonen> | manu1: another concern is that making stuff that the definers of HTML explicitly rejected conforming is going to give rise to annoying threads |
| 16:38 | <hsivonen> | manu1: I find it distressing that you don't seem to consider <p href> for RDFa purposes as an obviously bad idea |
| 16:38 | <manu1> | hsivonen: I don't think it's a good idea |
| 16:38 | <manu1> | hsivonen: but I don't think making it conforming is a bad idea either |
| 16:39 | <hsivonen> | manu1: do you believe all DOMs should be conforming? |
| 16:40 | <manu1> | hsivonen: I don't think it's necessary, no. |
| 16:40 | <manu1> | I agree that it would be nice... but authors stick all sorts of non-conforming stuff in their documents... is that the question you were asking? |
| 16:40 | <manu1> | (because your question could be interpreted a few different ways) |
| 16:41 | <hsivonen> | manu1: when authors stick crazy stuff in their documents, what should a validator say? |
| 16:41 | <manu1> | It should say: Hey, you've done something kinda crazy - you might want to do something else. |
| 16:41 | <hsivonen> | (note that I'm not contesting your processing model for <p href> in any way.) |
| 16:41 | <manu1> | (and give an example of an alternative) |
| 16:42 | <hsivonen> | manu1: should the definition of crazy be up to the validator developer or should spec try to define crazy? |
| 16:42 | <manu1> | If your argument is that a document conformance checker may want to kick out a warning, but not an error... then I think that'd be a fine thing to do for <p href> |
| 16:42 | <manu1> | I think it's very difficult for the spec to define what crazy is because there is a lot of crazy out there. |
| 16:42 | <hsivonen> | manu1: I'm saying I think a conformance checker should give an error for <p href> |
| 16:43 | <hsivonen> | lots of crazy out there hasn't stopped Hixie from being prescriptive in the HTML spec |
| 16:43 | <manu1> | I'm saying that I think a conformance checker should give a warning for <p href>... but not an error, because somebody may have a very good reason to do that. |
| 16:43 | <hsivonen> | manu1: do you have an example of a good reason? |
| 16:43 | <manu1> | For example... if you want to link each paragraph to the source of the document it came from, <p href> makes sense... |
| 16:44 | <manu1> | (for example - when referring to legislation in a government law or bill) |
| 16:44 | <hsivonen> | manu1: why not @resource? |
| 16:44 | <manu1> | Why not @href? :) |
| 16:44 | <manu1> | Not @resource because it's meant to override @href. |
| 16:44 | <hsivonen> | manu1: because @resource is understood not to be clickable |
| 16:45 | <manu1> | and then the argument becomes, why is <p resource> ok? |
| 16:45 | <manu1> | but <p href> is not. |
| 16:45 | <manu1> | hsivonen, it's not clickable in a browser-sense... but it is a hyperlink, none-the-less. |
| 16:45 | <manu1> | the same as @href. |
| 16:45 | <hsivonen> | It's OK (to the extent RDFa is "OK") because @resource has no clickability expectations but @href has |
| 16:45 | <manu1> | whether or not it is "click-able" is really a display issue. |
| 16:46 | <hsivonen> | manu1: that's a slippery slope towards someone asking for <p href> to become clickable |
| 16:46 | <manu1> | I think this really boils down to a philosophy on whether an HTML document is purely information... or if it is visual representation as well. |
| 16:46 | <manu1> | hsivonen: Yes, but if your concern is that we make <p href> clickable - I don't think anyone in their right mind would allow that to happen in a browser. |
| 16:47 | <manu1> | (and it's really the browser's prerogative) |
| 16:47 | <manu1> | (granted, at that point we have a huge argument on how to standardize the clickability of <p href> |
| 16:48 | <manu1> | but for now, I don't see anybody in their right mind saying that we need to change the visual display of <p href> to make sure that the user can click through to the @href that the <p> is pointing at) |
| 16:49 | <manu1> | I agree that /somebody/ at some point in time is going to ask you to make <p href> clickable... but at that point, I think the vast majority of us are going to say: That's insane... and keep going on our merry way making the Web better. |
| 16:49 | <hsivonen> | manu1: I guess you've never seen anyone ask for browser UI for <blockquote cite> |
| 16:49 | <manu1> | My point is: People are going to ask for crazy stuff... and we don't have to tell them "Yes." |
| 16:49 | Ms2ger | has |
| 16:49 | <annevk> | hsivonen: do you set responseXML.characterSet correctly? |
| 16:50 | <annevk> | I wonder what the correct interface for that is |
| 16:50 | <annevk> | spec-wise |
| 16:50 | <hsivonen> | manu1: it would be awesome if RDFa WG didn't say "Yes" to putting stuff like this in specs ;-) |
| 16:50 | <manu1> | hsivonen: :) |
| 16:50 | <hsivonen> | annevk: I don't know. |
| 16:51 | <hsivonen> | annevk: that's the kind of thing where I would expect Gecko to do the right thing, but you need a test case to be sure |
| 16:51 | <manu1> | hsivonen - I do think you have a valid concern, but I don't think the concern is strong enough to warrant the removal of @href, @rel and @rev everywhere (for the purposes of RDFa) |
| 16:52 | <manu1> | hsivonen - in any case, I'll put this down as Last Call feedback from you, so we'll have to discuss it... I just don't expect that we'll disallow it completely... maybe ask conformance checkers to kick out a warning - could you live with that decision? |
| 16:52 | <AryehGregor> | hober, can you explain to me why there's any such thing as transform-style: flat? Isn't transform-style: preserve-3d what you'd expect? |
| 16:53 | <hsivonen> | manu1: I'd probably escalate to the fun HTML WG Decision Process |
| 16:53 | <AryehGregor> | I don't see the value in transform-style: flat at all . . . you can emulate it by just adding scaleZ(0) at the end of the transform list for the element, no? |
| 16:53 | manu1 | cringes. |
| 16:53 | <manu1> | hsivonen - even in the case that conformance checkers kick out a warning? |
| 16:55 | manu1 | has to run, drop any other thoughts in here and I'll get to them once I'm back. Thanks for the comments, hsivonen :) |
| 16:55 | <manu1> | (they're always appreciated) |
| 16:56 | <hsivonen> | manu1: yes, even in the warning case |
| 17:03 | <annevk> | yeah seems to work |
| 17:06 | <dglazkov> | good morning, Whatwg! |
| 17:06 | <Ms2ger> | 'Night |
| 17:07 | <annevk> | should we add xhr.responseURL? https://www.w3.org/Bugs/Public/show_bug.cgi?id=15417 |
| 17:09 | <annevk> | I thought Gecko had fixed responseXML for non well-formed XML? |
| 17:09 | <annevk> | still returns some bogus tree |
| 17:10 | <annevk> | should we align XHR with DOMParser? |
| 17:14 | <smaug____> | annevk: last time I tried to make responseXML to not have that strange DOM tree, it broke some sites, IIRC |
| 17:16 | <annevk> | :/ |
| 17:22 | <AryehGregor> | hg people: is there some way to get rid of my local commits in hg? |
| 17:23 | <AryehGregor> | I.e., I don't have commit access and can't commit my changes and just want them to go away so I don't have to merge them for the rest of eternity. |
| 17:24 | <annevk> | I haven't found it |
| 17:24 | <smaug____> | hg strip works |
| 17:24 | <AryehGregor> | Or is this another case where the answer is "you have to use mq if you want hg to behave that way, stop trying to pretend it's git"? |
| 17:24 | <AryehGregor> | Hmm, okay. |
| 17:24 | <smaug____> | it is reasonable powerful |
| 17:24 | AryehGregor | will have to give in and learn mq anyway, probably |
| 17:24 | <smaug____> | so can do evil things if not used carefully, I think |
| 17:24 | <annevk> | ooh, extensions |
| 17:25 | <AryehGregor> | smaug____, right -- hg supports commands that are just as powerful as git, except without the clever idea of actually not destroying data, so in practice they're only usable by daredevils and masochists. |
| 17:25 | <AryehGregor> | Oh, this seems to have saved a backup of some kind. |
| 17:26 | <AryehGregor> | That's kind of it. |
| 17:27 | <smaug____> | I use hg strip all the time. Works fine for me |
| 17:27 | <AryehGregor> | Worked well enough for me, thanks. |
| 21:19 | <AryehGregor> | Is there an hg equivalent of git reset --mixed, i.e., "forget about all the adds/removes/mvs/etc. I scheduled but don't touch the working copy"? |
| 21:21 | <AryehGregor> | I'm trying to work around this: http://mercurial.selenic.com/bts/issue1686 |
| 21:21 | AryehGregor | gives up and does hg revert --all, then redoes the commit |
| 21:21 | <AryehGregor> | Or maybe I should just not use --git. |
| 21:21 | <Ms2ger> | Huh |
| 21:21 | <AryehGregor> | Oh, that just doesn't show moves/renames at all . . . ? |
| 21:21 | <Ms2ger> | Yeah |
| 21:21 | <AryehGregor> | Sigh. |
| 21:21 | <Ms2ger> | That's why we suggest --git :) |
| 21:27 | <Velmont> | Hmm, anyone know when sicking will be here? Have IndexedDB-questions. |
| 21:28 | <Velmont> | Or anyone else that could answer it :] |
| 21:30 | <jgraham> | Pretty sure no one apart from sicking understands indexdb |
| 21:30 | <jgraham> | Make of that what you will :) |
| 21:30 | <Velmont> | jgraham: Well, I asked here and was told to wait for sicking :P |
| 21:30 | <Velmont> | --> Trying to find any decision/answer about IndexedDB keypath and "." to seperate objects, anyone know anything about it? |
| 21:30 | <Velmont> | It's very possible I could get data from a third party that has a["my.value"] = thing, and I'd want to have a keypath that accesses my.value like that, not the property value on a my object. |
| 21:30 | <Velmont> | So either "my\.value" escaping, or similar stuff. |
| 21:31 | <jgraham> | Velmont: Yeah, I told you that iirc :) |
| 21:31 | <Velmont> | jgraham: Hehe, scrollback doesn't go that far back, so... :-) |
| 21:31 | <jgraham> | Velmont: You could try irc.mozilla.org I guess. |
| 21:32 | <Velmont> | But he's never in. He was in 10 minutes 07.15-07.27. Which wasn't really a great time for me :P |
| 21:46 | <matjas> | hsivonen: <a href=""http://code.google.com/p/chromium/issues/detail?id=112804>; typo |
| 21:48 | <annevk> | if he had omitted the quotes, it would have worked just fine |
| 21:48 | <annevk> | boo quotes |
| 21:48 | <annevk> | or you know, used a validator :p |
| 21:50 | <matjas> | http://mothereff.in/unquoted-attributes#http%3A%2F%2Fcode.google.com%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D112804 |
| 21:56 | <WeirdAl> | hi annevk: I'm wondering, does the XHR2 spec have those little browser-support icons that HTML5 has? |
| 21:56 | <WeirdAl> | I kinda liked that about Hixie's work |
| 22:00 | <zewt> | ugh, filing bugs on webkit/chrome is such a waste of time |
| 22:01 | <zewt> | because somehow the user is expected to figure out whether things are chrome or webkit bugs |
| 22:24 | <krijn> | TabAtkins: http://krijnhoetmer.nl/irc-logs/css/20120206#l-759 |
| 22:39 | <roc> | where can I file bugs on GMail? |
| 22:39 | <Hixie> | roc: what's the bug? |
| 22:40 | <roc> | every couple of minutes GMail pops up a message asking me to confirm that it should use rocallahan⊙mc as a backup address. I click "yes, this address is correct" and the message goes way, then comes back a bit later |
| 22:43 | <Hixie> | roc: do you have the exact text of the message? |
| 22:43 | <roc> | I'll give it to you when it comes back :-) |
| 22:43 | <roc> | there we go |
| 22:43 | <roc> | "Hey, this is important: If you ever lose access to your account, we can send password reset info to rocallahan⊙mc This address is correct | Update this address" |
| 22:47 | <Hixie> | roc: can you tell me your account e-mail address so i can put it in the bug report? (since it doesn't seem to happen to everyone so they might need it to track down the issue) |
| 22:47 | <roc> | rocallahan⊙gc |
| 22:47 | <roc> | thanks! |
| 22:48 | <roc> | although I can't help feeling that being a front-end to Google's bug database is an incredibly poor use of your time |
| 22:49 | <Hixie> | google has too many users to actually expose the bug database, unfortunately |
| 22:49 | <Hixie> | it would be completely unmanageable |
| 22:50 | <Hixie> | anyway, np |
| 22:50 | <Hixie> | i'll let you know if anything happens specifically on your bug |
| 22:50 | <Hixie> | it's probably a known issue so it'll probably just get aggregated down to some todo list somewhere and i'll never hear back :-P |
| 22:53 | <roc> | FWIW it only just started happening today |
| 22:54 | <Hixie> | noted |
| 22:55 | <roc> | Exposing our Bugzilla to hundreds of millions of users hasn't gone too badly, all things considered. As you scale out almost none of the extra users will be able to find or use the bug database anyway |
| 22:56 | <Hixie> | so this may surprise you, but there's actually a way to report bugs on google search results |
| 22:56 | <Hixie> | it's not obvious |
| 22:57 | <Hixie> | yet the volume we get is so high we basically can only handle it via automated aggregation |
| 22:57 | <Hixie> | dunno what the difference is between that and bugzilla |
| 22:57 | <roc> | SEO people gaming the system? :-) |
| 22:57 | <Hixie> | from what i've seen, it's not seo people |
| 22:57 | <Hixie> | just regular users |
| 22:59 | <Hixie> | roc: btw there actually is a way to file bugs on gmail directly if you want to try it that way and see if it works better than through me (dunno which works best!) |
| 23:00 | <roc> | ah, so there is |
| 23:00 | <roc> | now that I get off my arse and look for it |
| 23:01 | <roc> | I'll try it |
| 23:01 | <roc> | sorry |
| 23:01 | <Hixie> | no worries |
| 23:01 | <Hixie> | i didn't know it had shipped til just now :-P |
| 23:11 | <gavin> | Hixie: I just saw your "I've specced it" message in the "Can we deprecate alert(), confirm(), prompt() ?" thread, and am kind of wishing you'd included a link to a changelog or something |
| 23:11 | <gavin> | is there an easy way for me to look something like that up? |
| 23:11 | <Hixie> | http://html5.org/tools/web-apps-tracker |
| 23:11 | <gavin> | ah |
| 23:12 | <Hixie> | i can't include the link to that when writing the e-mail because the process of generating the spec and committing the change takes a long time, which is the time i use to reply to the e-mail and move on to the next one :-) |
| 23:12 | <Hixie> | you can also subscribe to get all the changes by e-mail, on a per-topic basis |
| 23:13 | <Hixie> | see the "Edit subscriptions" button at the top right of the spec |
| 23:13 | <gavin> | I don't generally want to subscribe to changes, I just want to look up the ones that interest me (I was working on disabling dialogs onunload in gecko) |
| 23:13 | <Hixie> | ah ok |
| 23:13 | <gavin> | I always end up looking for the change tracker thing and can't find it |
| 23:14 | <gavin> | anyways, thanks :) |
| 23:14 | <Hixie> | there's a link to it in the header of the spec |
| 23:14 | <Hixie> | under "Version history" |
| 23:14 | <Hixie> | also all the changes are tweeted https://twitter.com/#!/whatwg :-) |
| 23:14 | <Hixie> | those include a link to the diff |
| 23:53 | <Hixie> | bummer. time to add a global attribute. |
| 23:53 | Hixie | hates adding new attributes and elements |
| 23:54 | <Hixie> | (mostly because of the indexes) |