| 00:01 | <MikeSmith> | http://stackoverflow.com/questions/33146029/seeing-if-a-request-succeeds-from-within-a-service-worker |
| 20:27 | <Domenic> | We should really get around to removing the outline algorithm |
| 20:31 | <tantek> | agreed |
| 21:42 | <MikeSmith> | Domenic: tantek Why? |
| 21:43 | <tantek> | insufficient implementation, having it be in the spec is misleading (affords it implied status that is inaccurate) |
| 21:53 | <MikeSmith> | there's actually nothing in the spec for browsers to implement |
| 21:54 | <tantek> | the outline algorithm itself presumably |
| 21:54 | <MikeSmith> | nothing exposed to web content |
| 21:54 | <tantek> | great, then move it to a non-normative appendix |
| 21:54 | <tantek> | though I thought it was somehow exposed in the DOM, no? |
| 21:54 | <MikeSmith> | nope |
| 21:55 | <tantek> | then a non-normative appendix is a good start to moving it out. |
| 21:55 | <MikeSmith> | So why not let's actually add a requirement? |
| 21:55 | <MikeSmith> | Element.createOutline() |
| 21:55 | <tantek> | because no implementer has cared enough to date to ask for it |
| 21:55 | <tantek> | features by default should be deleted |
| 21:56 | <tantek> | not solutions looking for problems |
| 21:56 | <MikeSmith> | or alternately document.createOuline(element) |
| 21:57 | <MikeSmith> | implementors are typically not the ones who ask for such features |
| 21:57 | <MikeSmith> | And it's not a solution looking for a problem |
| 21:58 | <MikeSmith> | The core problem is the fact that we added section and article |
| 21:58 | <tantek> | I'm kind of done with those too |
| 21:59 | <MikeSmith> | The outline algorithm is a necessary consequences of having done that |
| 21:59 | <tantek> | If it were necessary it would have been implemented. So no. |
| 21:59 | <MikeSmith> | tantek: well the language is stuck with those elements now |
| 21:59 | <tantek> | is it? if no one does anything particularly interesting with them they turn into aliases for div |
| 22:00 | <MikeSmith> | sometimes having discussions with you really bums me out man |
| 22:02 | <MikeSmith> | https://github.com/whatwg/html/issues/83#issuecomment-136882847 |
| 22:02 | <MikeSmith> | Anyway I agree with what Hixie said there |
| 22:05 | <gsnedders> | MikeSmith: how do a11y tools get at the outline? do they get it from the DOM tree? from the a11y tree-thing? |
| 22:05 | <MikeSmith> | and otherwise in general for 2016 l think literally I'm going to seriously try to adopt a communication mode where I try very hard to project a positive vibe and not unintentionally bum people out |
| 22:05 | <gsnedders> | I should really understand how the a11y layers work better. |
| 22:06 | <MikeSmith> | They don't do anything with it |
| 22:06 | <gsnedders> | I thought most a11y stuff had ways to jump between sections? |
| 22:06 | <MikeSmith> | They just do a naive outline based on the headings |
| 22:06 | <gsnedders> | Or is that just jump between sections? |
| 22:07 | <MikeSmith> | naive headings level |
| 22:07 | <MikeSmith> | Yeah they provide jumping |
| 22:07 | <gsnedders> | So do they have *any* concept of an outline? |
| 22:07 | <MikeSmith> | But they do not understand nested h1 |
| 22:07 | <gsnedders> | Right, that's not what I'm asking. |
| 22:08 | <MikeSmith> | no they do not |
| 22:08 | <gsnedders> | I'm asking do they have an outline or do they have "jump to next heading in document order"? |
| 22:08 | <MikeSmith> | They treat every h1 as a top level heading |
| 22:08 | <gsnedders> | Do they have a concept of levels of heading? |
| 22:09 | <gsnedders> | If they do, do we not need a conformance class for accessibility tools? |
| 22:09 | <MikeSmith> | They create a naive hierarchy based just on h1 to h6 |
| 22:10 | <MikeSmith> | So you can navigate to/through all the H2 headings etc |
| 22:10 | <gsnedders> | Right. So all we're asking them to change (currently) is how they build their hierarchy. OK. |
| 22:10 | <MikeSmith> | yeah |
| 22:12 | <MikeSmith> | the way I address this problem in the HTML checker is to emit a warning if an h1 is used in a nested section or article |
| 22:12 | <gsnedders> | So again: Do we need a new conformance class for accessiblity tools? |
| 22:12 | <MikeSmith> | that is, other than at the top level |
| 22:12 | <gsnedders> | Because currently there isn't one that applies for stuff like that. |
| 22:13 | <MikeSmith> | We already have that conformance class, I think |
| 22:13 | <MikeSmith> | But if not, yeah, we should add it |
| 22:13 | <MikeSmith> | definitely |
| 22:14 | <gsnedders> | I guess half the problem is the mismatch of things exposed via the accessibility APIs on different platforms |
| 22:14 | <gsnedders> | and by different rendering engines |
| 22:15 | <MikeSmith> | btw I also tried to address this need in the HTML checker by adding a Show Outline feature. which many people do useー just as many did use the Show Outline feature of the legacy W3C markup validator |
| 22:15 | <MikeSmith> | gsnedders: yeah |
| 22:17 | <MikeSmith> | Steve Faulkner has been working to try to erase that mismatch and get more interoperability for a11y APIs |
| 22:17 | <MikeSmith> | he edits a related spec |
| 22:20 | <gsnedders> | I guess some of the problem is that much of that is OS level |
| 22:25 | <MikeSmith> | yup |
| 22:32 | <MikeSmith> | but IMHO another problem is that the a11y tree is not exposed to Web content |
| 22:33 | <MikeSmith> | it's one of the cases where the browser is doing something important and useful but Web developers have no way to observe it or examine it from script |
| 22:35 | <MikeSmith> | IMHO we need an a11y abstraction above the platform APIs, that is exposed for scripts to observe |
| 22:38 | <MikeSmith> | what I mean is, if you look at http://rawgit.com/w3c/html-api-map/master/index.html#el-article |
| 22:39 | <MikeSmith> | it shows that, depending on the platform API, <article> gets mapped to some thing called either ROLE_SYSTEM_GROUPING or ROLE_SYSTEM_DOCUMENT or ATK_ROLE_DOCUMENT_FRAME or AXDocumentArticle |
| 22:40 | <MikeSmith> | so we should just have one standard abstract defined thing/name that it gets mapped to, and that should be exposed to scripts |
| 22:40 | <MikeSmith> | and the tree of such things that browser engines create should be exposed to scripts |
| 22:44 | <MikeSmith> | and anyway I think what this shares with this outline-algorithm issue is that in general when you have specs defining things or stating requirements that normal Web developers have no way to observe and test from there Web application code, we're gonna have problems |
| 22:48 | <MikeSmith> | in other news http://stackoverflow.com/questions/34473930/service-worker-caching-requests-for-one-time-urls-without-ignoresearch is interesting |
| 22:48 | <MikeSmith> | one-cache-per-file SW caching |
| 22:49 | <MikeSmith> | "A few gotchas. With this approach, you’ll need to roll your own cache-expiration logic." |
| 23:44 | <Domenic> | MikeSmith: I think the problem is that HTML right now has an abstract notion of author-facing semantics which are actively in conflict with user-facing semantics as implemented by a11y tools |
| 23:44 | <Domenic> | I'd like to bring them in line |
| 23:44 | <Domenic> | Since a11y tools and browsers have stated they will not change, we should change the author-facing abstract semantics |