| 02:29 | <stevefaulkner> | JonathanNeal: yeah JAWS sometime interrogates the DOM directly and applies role mappings if not exposed via API |
| 02:30 | <JonathanNeal> | stevefaulkner: so is it a matter of being redundant for others? |
| 02:32 | <stevefaulkner> | JonathanNeal: if you want to support AT other than later JAWS then yeah |
| 02:33 | <JonathanNeal> | which AT? |
| 02:35 | <stevefaulkner> | NVDA, WE, VoiceOver, supernova |
| 02:37 | <stevefaulkner> | Orca |
| 02:37 | <JonathanNeal> | VoiceOver gives no distinction between <nav> and <nav role="navigation"> |
| 02:39 | <JonathanNeal> | In fact, it gives no distinction between <nav> and <div>. Not in the text prompt and not in the voice prompt. |
| 02:42 | <stevefaulkner> | JonathanNeal: your statement is not helpful without some more info = what version of VoiceOver and OS and what Browser /version |
| 02:44 | <JonathanNeal> | Well, it was as descriptive as yours :) VoiceOver 6, Mountain Lion, Chrome 22. |
| 02:45 | <JonathanNeal> | Same in Safari 6.0.1 |
| 02:48 | <stevefaulkner> | then i suggest you are doing something wrong as in Safari 6 etc thereI get a difference |
| 02:49 | <JonathanNeal> | I'll try it again, with and without role="navigation" on the <nav> |
| 02:50 | <JonathanNeal> | Yea, nothing about role="navigation". |
| 02:51 | <stevefaulkner> | JonathanNeal: will check in morning and get back to you |
| 02:51 | <GPHemsley> | Hixie: What did Web Controls evolve into? |
| 03:00 | <GPHemsley> | http://ln.hixie.ch/?start=1140242962&count=1 |
| 03:05 | <GPHemsley> | http://ln.hixie.ch/?start=1144794177&order=-1&count=1 |
| 03:08 | <GPHemsley> | http://ln.hixie.ch/?start=1154950069&order=-1&count=1 |
| 03:08 | <GPHemsley> | http://www.w3.org/2001/tag/doc/mime-respect-20060412 |
| 03:19 | <GPHemsley> | http://ln.hixie.ch/?start=1170104775&order=-1&count=1 |
| 03:19 | <GPHemsley> | "Don't fall into the temptation of discussing the meaning of the word "meaning"." |
| 03:20 | <GPHemsley> | http://www.w3.org/mid/20070129180343.GG1946⊙co |
| 03:24 | <GPHemsley> | Hey, remember that time when Acid3 was a thing? |
| 04:13 | <jackolant> | This is kind of awkward, but I never seem to understand the relationship between Mozilla, W3C and WhatWG. |
| 04:13 | <jackolant> | All three have specifications and examples and documents and proposals and drafts and standards... |
| 04:14 | <jackolant> | It seems as if Mozilla Developer Network is the "bible" somehow. |
| 04:14 | <jackolant> | Yet it's written as articles, often in a non-formal fashion. |
| 04:38 | <Hixie> | GPHemsley: evolved into rot. :-( |
| 04:39 | <Hixie> | jackolant: mozilla is a browser vendor, any proposals and drafts are "just" proposals (proprietary, in a way, though maybe not with any more or less buy-in than what i'm about to talk about) |
| 04:39 | <jackolant> | :S |
| 04:39 | <Hixie> | jackolant: w3c, ietf, and whatwg are different standards organisations that work on web techs |
| 04:39 | <jackolant> | I have never heard of IETF before now, and I've read a lot... |
| 04:39 | <Hixie> | jackolant: w3c and whatwg work on higher-level stuff like html, ietf on lower-level stuff like TCP/IP and URLs and DNS |
| 04:40 | <Hixie> | (afk bbiab, if you want more detail) |
| 04:41 | <jackolant> | Hmm. |
| 04:42 | <jackolant> | Well, basically, whenever I need to look something up, I open MDN which I have bookmarked and search for a keyword. |
| 04:42 | <jackolant> | I get a bunch of results which is usually an article which seems to be in wiki format. |
| 04:42 | <jackolant> | This feels very non-formal. |
| 04:42 | <jackolant> | They also link to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element |
| 04:42 | <jackolant> | This page in itself feels very slow and strange. |
| 04:43 | <jackolant> | I wish they would lock themselves in for a few weeks non-stop and come out with a Bible with a version number. |
| 04:43 | <jackolant> | And then that's THAT. |
| 04:43 | <jackolant> | It's fixed. |
| 04:43 | <jackolant> | Never touched again. |
| 04:43 | <jackolant> | Then they do the same thing a few months later. |
| 04:43 | <jackolant> | And use all the feedback etc. |
| 04:43 | <jackolant> | And then another Bible is done. |
| 04:44 | <jackolant> | Never to be touched again. |
| 04:44 | <jackolant> | This "living standard" stuff is asking for confusion and problems IMO. |
| 04:46 | <Hixie> | jackolant: you want us to only release things every two months instead of every two hours? |
| 04:47 | <Hixie> | jackolant: so if we find an error we should wait before we fix it? |
| 04:49 | <jackolant> | Well... my main message with that speech was that there needs to be some "milestones". |
| 04:49 | <jackolant> | Like "stable releases". |
| 04:50 | <jackolant> | And not like many FOSS projects where the stable version is ancient and you are expected to use the very latest bleeding edge one. |
| 04:50 | <jackolant> | Even if you do fix some error immediately, that is still just a specification and the implementators will need to implement it. |
| 04:54 | <Hixie> | what purpose does a milestone spec serve? |
| 04:54 | <Hixie> | all it would do is mean the people following the spec were following something that was wrong |
| 04:54 | <Hixie> | which would mean the browsers would be even more buggy |
| 05:00 | <zewt> | <jackolant> Never touched again. <- that smells very IETF to me |
| 05:08 | <jackolant> | The point is that a fixed version would be released. |
| 05:08 | <jackolant> | Without changing the old one. |
| 05:08 | <Hixie> | but of what use would that be? |
| 05:08 | <jackolant> | "If you follow this version, you can be sure that this what you work with." |
| 05:08 | <jackolant> | There's a lot of old software that has bugs that people depend on... |
| 05:09 | <Hixie> | oh, i see the misunderstanding |
| 05:09 | <Hixie> | browsers don't implement the specs the way you think |
| 05:09 | <jackolant> | :S |
| 05:09 | <Hixie> | it's not like we release a spec in december and all the browsers release an update that exactly matches the spec |
| 05:10 | <Hixie> | nor do the browsers behave differently for pages written in 2010 than pages written in 2011 (or 2001) |
| 05:10 | <jackolant> | By the way, there needs to be a way to directly get/set/manipulate pixels of images... looping through the imageData in JS is extremely slow. |
| 05:11 | <Hixie> | yeah, there's work on making gpu-based thingies to do image manipulation |
| 05:11 | Hixie | hands off to zewt to handle the questions about spec development and releases and goes to watch some TV |
| 05:11 | <Hixie> | bbl :-) |
| 05:11 | <jackolant> | My browser crashed. |
| 05:14 | <Hixie> | (case in point, no spec has ever said that the browser should crash :-) ) |
| 05:15 | <jackolant> | Opera seems to be crashy every other version. |
| 05:15 | <jackolant> | And stable every other version. |
| 05:15 | <jackolant> | I mean "stable" ones. |
| 06:38 | <annevk> | whoa, I found some clean Gecko code |
| 06:38 | <annevk> | http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#1544 |
| 06:41 | <Yuhong> | <Hixie> it's not like we release a spec in december and all the browsers release an update that exactly matches the spec |
| 06:42 | <Yuhong> | Similar reasons are why I consider the term "HTML5" a misnomer even as a buzzword. |
| 06:42 | <Yuhong> | <Hixie> nor do the browsers behave differently for pages written in 2010 than pages written in 2011 (or 2001) |
| 06:45 | <Yuhong> | Validators did, and I was considering versioned HTML specs for validators only, but then I realized that it would only promote the misuse of the term as a buzzword. |
| 07:07 | <annevk> | GPHemsley: you forgot to lowercase SHOULD NOT, MAY, etc. And you also still use some of those in a class=note which is wrong. |
| 07:53 | <annevk> | Neither Opera nor Mozilla normalize IPv6 addresses |
| 07:53 | <annevk> | in URLs |
| 07:54 | <annevk> | And neither does Safari |
| 07:54 | <annevk> | man, that's boring |
| 07:55 | <annevk> | I hope they're all willing to change that |
| 09:14 | <annevk> | I think I said this before, but figuring out where domain names are actually defined is extremely hard and thus far I've only found non-host-name RFCs mentioning the trailing dot; the few ancient RFCs with actual syntax definitions do not mention it |
| 09:15 | <annevk> | You'd hope something as essential as that is nailed down in beautiful prose with lots of tests... but you'd be wrong. |
| 09:19 | <annevk> | http://en.wikipedia.org/wiki/Domain_Name_System#Domain_name_syntax does not even mention the trailing dot |
| 09:19 | <annevk> | and none of the RFCs it references do either afaict |
| 10:15 | <Stevef_> | JonathanNeal: with this test file https://dl.dropbox.com/u/377471/tests/navtest.html voiceOver+safari 6 announces when entering and leaving <nav> <nav role="navigation"> or <div role="navigation"> as expected as <nav> is exposed as role=navigation. in chrome <nav> is not exposed as role=navigation all esle is the same as safari. when llinks are organised as list then number of items and... |
| 10:15 | <Stevef_> | ...current position in list is announced, this does not occur in <nav> without list |
| 10:21 | <Stevef_> | JonathanNeal: so my advice is is if you want more robust support for exposing nav semantic use <nav role="navigation">, if links are organized as a list visually mark them up as a list otherwise the semantics implied by visual organization is lost. |
| 10:35 | <annevk> | would be nice if they fixed voice over to just list the number of <a>s in a <nav> |
| 10:37 | <hober> | annevk: file a bug? :) |
| 10:38 | <annevk> | nah, I hunt for bugs that warrant module rewrites :p |
| 10:41 | <hober> | heh |
| 10:43 | <Stevef_> | annevk: that may work for simple lists, not so for nested link lists |
| 10:48 | <annevk> | hmm, browsers don't even agree whether http://example%2eorg/ should work |
| 10:48 | <annevk> | Stevef_: sure, you need some heuristics |
| 10:49 | <annevk> | but you do with lists too, they might be weird after all |
| 10:51 | <Stevef_> | annevk:what heauristics do you need with lists? the item number and nesting are explicit |
| 10:52 | <Ms2ger> | Ah, CSSWG F2F meetings are always fun |
| 10:52 | <Ms2ger> | > jet proposes discussing the travelling salesman problem instead |
| 10:53 | <annevk> | Stevef_: e.g. if <ol> contains a <div> directly or contains another <ol> directly (developer mistakes) |
| 10:54 | <smaug____> | uh, waking up early enough for tpac will be hard |
| 10:54 | <annevk> | will you be there smaug____? |
| 10:54 | <smaug____> | I will |
| 10:55 | <annevk> | sweet, I think last time was two years ago and we only briefly said hi :) |
| 10:55 | <hober> | Ms2ger: it's even better live |
| 10:55 | <annevk> | CSS is meeting today? |
| 10:56 | <Ms2ger> | Yeah |
| 10:56 | <Ms2ger> | And they resolved to get transforms to CR in a few weeks |
| 10:56 | <annevk> | hober: want to have dinner tonight then? I land at 5PM, should be at the hotel around 6/6:30PM I hope |
| 10:56 | Ms2ger | had some fun pointing out that was resolved in February too |
| 10:57 | <Stevef_> | annevk: <ul><div>... does not effect effect properties of list in accessibility tree |
| 10:57 | <annevk> | Ms2ger: "and we really mean it!11!" |
| 10:57 | <hober> | annevk: sure! erin and i aren't staying at the official hotel though. |
| 10:57 | <annevk> | hober: I'm staying at the Hilton and I've no idea where anything is :) |
| 10:57 | <annevk> | hober: guess I'll find out |
| 10:58 | <hober> | annevk: we're at the roosevelt |
| 10:58 | <annevk> | Stevef_: and <ul><div><li>test</li></div><li>test</ul> and things like that? anyway, you don't really need to test, was just saying |
| 11:01 | <Stevef_> | annevk: I would suggest if the nav element implies a list then it should be implemented as such in browser, so accessibility tree exposes in this way |
| 11:03 | <annevk> | Stevef_: suggest to me? I'm not representing anyone... |
| 11:04 | <Stevef_> | annevk: didn't say you were, suggest in the general sense and heuristics should be implemented browser side rather than AT side |
| 11:05 | <annevk> | I would rather leave that up to implementors, might be that some AT developers prefer a simple interface to innovate upon whereas others have easy access to the underlying browser and can innovate there... |
| 11:13 | <Stevef_> | from what i gather from AT developers they want semantics exposed via acc APIs so they don't have to go digging through the DOM driectly, also there is a much better chance of interop if stuff is exposed interop by the lmited number of browser engines as against the greater number of AT |
| 11:13 | <Stevef_> | exposed uniformly that is |
| 11:19 | <Stevef_> | and applying heuristics browser side (as friefox does for layout tables) does no preclude innovation on the AT side... |
| 11:26 | <annevk> | kinda surprising there's more AT than browsers yet they're generally perceived (at least a while back when I still followed this stuff) as crappy |
| 11:31 | <Stevef_> | part of the crappiness of AT is due to crappiness of browser accessibility support, but people have overlooked or not understood that in the past and now |
| 11:33 | <Stevef_> | that is evident when you look at how well NVDA works with Firefox for example goood browser acc implementation = good AT = happy users |
| 11:45 | <Stevef_> | in contrast to Opera, which does not work in any practical sense with any screen reader and works poorly with screen magnifiers |
| 12:05 | <annevk> | matjas: if you read the logs, I'll acknowledge you in the next commit for the domain label separator testing stuff |
| 12:05 | <annevk> | matjas: in the URL Standard, forgot it in this commit |
| 12:06 | <AryehGregor> | annevk, are you planning on looking at this anytime soon? I'd like to fix either Gecko or my test, as the case may be. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19555 |
| 12:08 | <annevk> | AryehGregor: I'm not sure how to fix it |
| 12:08 | <AryehGregor> | annevk, meaning you're not sure what we want, or you're not sure how to spec it? |
| 12:09 | <annevk> | either I suppose |
| 12:09 | <AryehGregor> | What's the rationale for not matching what all browsers do? |
| 12:09 | <AryehGregor> | Granted it's awkward and confusing, but so is the whole API, and jQuery might depend on it. |
| 12:10 | <AryehGregor> | Plus, we'd be making the API strictly less useful than it already is -- there's no other good way to do what it does (if there's any way at all). |
| 12:11 | <annevk> | I tried to simplify the method with what I thought I could get away with |
| 12:11 | <annevk> | I also don't like "implementation specific" ever |
| 12:11 | <annevk> | I don't mind specifying something else though, but I'm not sure what exactly and how to specify it, in particular the bit about disconnected nodes and order |
| 12:12 | <AryehGregor> | The idea is just that you might want to order a list of nodes in some fashion that will work for .sort(). |
| 12:12 | <annevk> | sure, but what the fuck does "then the order is based upon order between the root container of each node that is in no container" mean? |
| 12:14 | <AryehGregor> | It really means "if you compare two nodes that don't have the same root, the order is determined by comparing the pointers to their respective roots, assuming the pointer to a node remains constant across its lifetime". But the spec doesn't want to say that. |
| 12:15 | <annevk> | does root here mean the "node document"? |
| 12:15 | <annevk> | nodes don't have a root |
| 12:15 | <AryehGregor> | No, it means the furthest ancestor. |
| 12:16 | <annevk> | a = document.createElement("a"); what's the root here? |
| 12:16 | <AryehGregor> | Specifically, the algorithm for comparing two nodes that don't have the same root are: 1) Let A and B be the nodes. 2) While A's parent is not null, set A to its parent. 3) While B's parent is not null, set B to its parent. 4) Return the result of comparing A and B according to some sort function that stably and totally orders all nodes. |
| 12:16 | <AryehGregor> | annevk, function root(node) { while (node.parentNode) node = node.parentNode; return node; } |
| 12:16 | <AryehGregor> | I don't know what the current DOM spec calls that, offhand. |
| 12:17 | <annevk> | might call it root actually, hmm |
| 12:17 | <annevk> | or furthest inclusive ancestor |
| 12:17 | <annevk> | maybe |
| 12:17 | <AryehGregor> | http://dom.spec.whatwg.org/#concept-tree-root |
| 12:18 | <annevk> | so anyway, that sort function being undefined does not strike me as a good solution |
| 12:18 | <annevk> | that will trip up people (and I believe it already does) |
| 12:18 | <AryehGregor> | It can't meaningfully be defined. |
| 12:18 | <AryehGregor> | How do you propose to define it? |
| 12:19 | <AryehGregor> | In practice, Gecko uses pointer comparison, and I'm guessing so do IE/Opera. |
| 12:19 | <annevk> | dunno, latest created node is following? |
| 12:19 | <annevk> | but that's kinda awkward too |
| 12:19 | <AryehGregor> | How do browsers keep track of it? |
| 12:19 | <AryehGregor> | They're not going to add overhead for the sake of this method. |
| 12:19 | <AryehGregor> | Also, it's not immediately obvious to me that that's well-defined, although it might be. |
| 12:20 | <AryehGregor> | (e.g., are there any methods that create multiple nodes at once?) |
| 12:20 | <annevk> | never mind, it was just a thought |
| 12:20 | <Ms2ger> | (anything to do with innerhtml?) |
| 12:21 | <annevk> | I have to pack a few more things and go, maybe add a pointer to the bug about this discussion and just go with the DOM3 behavior for now |
| 12:22 | <annevk> | it's evil, but I can't think of anything better |
| 12:23 | <AryehGregor> | Same conclusion I reached. |
| 13:23 | <annevk> | AryehGregor: coming to TPAC? |
| 14:13 | <annevk> | made it into the plane, close call... |
| 14:13 | <annevk> | that hour extra didn't really help me |
| 15:14 | <tantek> | greetings and good morning |
| 15:15 | <tantek> | I'm thinking of editing the ContactsAPI in the WHATWG github. Is there any particular process to follow, or do I just create a new repository and go? |
| 15:15 | <tantek> | It's likely that the new W3C SysApps WG will publish snapshots of the ContactsAPI under the W3C license, but I prefer to edit it in a more open CC0+OWFa state. |
| 15:16 | <tantek> | And lastly, are there any other WebAPI/ContactsAPI implementers here who would like to co-edit? |
| 15:16 | <tantek> | this is the source material I'll be starting with: https://wiki.mozilla.org/WebAPI/ContactsAPI |
| 15:17 | <tantek> | I'll likely leave all the feature request evaluation type stuff in that wiki page, but the goal is to move the API pieces to a specification in a shared location. |
| 16:26 | <Ms2ger> | var parent = document.createElementNS("http://www.w3.org/1999/xhtml";, "html:table") |
| 16:26 | <Ms2ger> | w(parent.tagName) |
| 16:26 | <Ms2ger> | Anybody want to guess what you get? |
| 16:27 | <Philip`> | I bet it will be something that's totally natural and logical and well defined and the same across all implementations |
| 16:27 | <Ms2ger> | How much would you bet on that? |
| 16:28 | <Philip`> | Something that is of no value to me |
| 16:29 | <Ms2ger> | Dammit |
| 16:29 | <Ms2ger> | Because I'd totally win that :) |
| 16:30 | <Ms2ger> | Boo, only three different results in four browsers |
| 16:31 | <Philip`> | I've got a 1 Swedish krona coin which I got from a supermarket instead of 10 pence - you could have that, if you want to come and pick it up |
| 16:32 | <Ms2ger> | I'll come over on the pretense of picking up that coin, and instead kidnap you to work on canvas tests |
| 16:32 | <Ms2ger> | ... Did I say that out loud? |
| 16:35 | <zcorpan> | Philip`: i can take your coin if you're at tpac |
| 16:36 | <SimonSapin> | Ms2ger: I guess not many of us have text-to-speech IRC clients … so not out loud |
| 16:37 | <zcorpan> | Ms2ger: is it HTML:TABLE per spec? |
| 16:37 | <Ms2ger> | Yes |
| 16:38 | <Ms2ger> | (Opera: html:TABLE; Chrome: html:table; IE+Gecko: HTML:TABLE) |
| 16:39 | <zcorpan> | uh, i get undefined in opera 12.02 ...?? |
| 16:39 | <Ms2ger> | ?? |
| 16:40 | <Ms2ger> | Works fine on 12.50/1538 |
| 16:40 | <Ms2ger> | Now, a continuing question... |
| 16:40 | <zcorpan> | oh, parent |
| 16:41 | <zcorpan> | parent is unforegable |
| 16:41 | <Ms2ger> | Oh, yay |
| 16:41 | <zcorpan> | html:TABLE with a variable name that works |
| 16:42 | <Ms2ger> | Now add... |
| 16:42 | <Ms2ger> | var row = parent.insertRow(-1); |
| 16:42 | <Ms2ger> | w(row.tagName) |
| 16:44 | <zcorpan> | Ms2ger: are you writing this down in a proper test case? |
| 16:44 | <Ms2ger> | Yeah |
| 16:44 | <zcorpan> | excellent |
| 16:45 | <Ms2ger> | (Gecko: HTML:TR, non-Gecko: TR) |
| 16:48 | <zcorpan> | Ms2ger: nice email |
| 16:49 | <Ms2ger> | Thanks |
| 16:49 | Ms2ger | hates those tests |
| 16:50 | <jgraham> | I support removing all tests that are wrong |
| 16:58 | <zcorpan> | speaking of tests, i'm working a bit on http://simon.html5.org/test/css/css-charset/ (i'll put this somewhere better when there's more coverage) |
| 17:06 | <zcorpan> | AryehGregor: annevk: ^ |
| 17:10 | zcorpan | finds http://html5.org/temp/cssencoding.txt again |
| 17:29 | <zcorpan> | AryehGregor: annevk: btw seems browsers don't bother with the step "1. Let encoding be utf-8." |
| 17:30 | <zcorpan> | (if you load a css file in a top-level browsing context, seems to use the same rules as text/plain basically) |
| 17:35 | <Ms2ger> | jgraham, agreed with your reorganization if you use dashes like I did :) |
| 17:38 | <jgraham> | Ms2ger: heh |
| 18:02 | <GPHemsley> | annevk: I only lowercased the words in the sections I've worked on. (I'm in the process of rewriting the whole thing to be clearer and more integrated.) |
| 18:15 | <GPHemsley> | annevk: Same goes for their use in notes. |
| 18:23 | <Yuhong> | <Hixie> it's not like we release a spec in december and all the browsers release an update that exactly matches the spec |
| 18:23 | <Yuhong> | Similar reasons are why I even consider "HTML5" a misnomer even as a buzzword. |
| 20:16 | <hsivonen> | where should one get dinner in the TPAC area? |
| 20:17 | <Ms2ger> | I'd tend to look at the w3c-css-wg archives |
| 20:22 | <hsivonen> | w3c-css-wg didn't help |
| 20:22 | <hsivonen> | I guess I'll head to the first place with areasonable menu in Cité international |
| 20:31 | <GPHemsley> | Gmail marked a list e-mail from the Chrome team as spam ^_^ |
| 20:41 | <Ms2ger> | It always does |
| 21:35 | <Hixie> | jgraham: re directories for testing, one thing to keep in mind is to make sure there's room in the organisation for tests that check interactions and thus don't fit neatly into categories |
| 22:56 | <wilhelm> | 1. Drink wine. 2. Write agenda for WG meeting. 3. ??? |
| 23:13 | <zewt> | goto 1 |