| 04:12 | <MikeSmith> | jyasskin: while browsers can infer the language without lang=, accessibility software / screen readers like JAWS do not, which leads to a lot of problems for users who do their browsing with those |
| 04:14 | <MikeSmith> | jyasskin: one common problem is that the lang value does not actually match the language of the content of the page (due to authors cargo-cult copy/pasting the html element and attributes from, e.g., a lang=en page into a page whose contents are actually in Chinese or whatever |
| 04:16 | <MikeSmith> | jyasskin: so in order to help authors catch those kinds of mistakes, and help users of screen readers, the proposal is that the HTML checker would do language detection on the content of each document, and warn if the lang value does not match the detected language |
| 04:19 | <jyasskin> | Oh, it doesn't use the browser's accessibility tree? That would break my suggestion, yeah. |
| 04:19 | <MikeSmith> | I don’t know that the detected lang information gets into the accessibility tree from the browser |
| 04:20 | <MikeSmith> | but anyway the best solution to the problem for screen-reader users would be if screen readers also did language detection the way that browsers do |
| 04:20 | <MikeSmith> | because of course they operate on content other than Web content |
| 04:20 | <jyasskin> | But second-best might be the browsers putting detected information into the tree. |
| 04:21 | <MikeSmith> | yeah |
| 04:27 | <MikeSmith> | jyasskin: btw do you know what Chrome does in cases where the lang value does not match the detected language? I mean as far as the Translate prompt or any other user interaction? Does it just ignore the lang value? |
| 04:27 | <jyasskin> | I don't know offhand. I'd guess it ignores the lang value, especially if it's 'en', but would have to check. |
| 04:27 | <MikeSmith> | OK |
| 04:28 | <MikeSmith> | well if it does just ignore it, that suggests the presence of top-level html@lang is not actually very useful in practice on the Web (though having lang values on other sections of the document that are in other languages would be) |
| 04:35 | <MikeSmith> | it is sad that so many of our discussions about making user experience better for screen-reader users come down to, “Vendors of screen readers can’t or won’t make their products smarter, so let’s all do a bunch of extra work in N different browsers and other tools to work around all the longstanding deficiencies in screen readers.” |
| 04:41 | <jyasskin> | MikeSmith: After searching, the code to detect the page's language does use the declared lang attribute and Content-Language HTTP header: https://code.google.com/p/chromium/codesearch/#chromium/src/components/translate/core/language_detection/language_detection_util.cc&l=184. Once the language is detected, the rest of Chrome appears to only use the return |
| 04:41 | <jyasskin> | value of DeterminePageLanguage() to drive the actual translation. |
| 04:42 | <MikeSmith> | jyasskin: OK, thanks |
| 04:43 | <MikeSmith> | yeah that makes sense, given that the lang value and header really should not be trusted |
| 04:44 | <MikeSmith> | but that makes me really wary about having the HTML checker warn about a missing html@lang value. Given the circumstances, Not sure how helpful that will actually be for end users in practice |
| 04:45 | <MikeSmith> | I mean without having the checker also implement language detection |
| 04:48 | <MikeSmith> | I think I should probably only have the checker emit a warning for missing lang if it is able to detect the language, so the warning would be of the form, “The contente of this document appears to be in Chinese, consider putting an lang=zh value on the html element.” |
| 05:00 | <tantek> | MikeSmith: that seems reasonable |
| 05:04 | <MikeSmith> | just wish I had a streaming langague-detection library |
| 05:05 | <MikeSmith> | I guess I could write a streaming implementation on top of an existing library |
| 05:52 | <annevk> | rniwa: am now... |
| 06:20 | <annevk> | Ugh, Permissions API going straight for the API instead of figuring out the model is biting us now 😟 |
| 06:22 | <annevk> | I wonder when we'll learn that in order to make a good API you first need to figure out how the system works |
| 06:32 | <rniwa_> | @annevk: I was gonna ask you about this: https://github.com/w3c/webcomponents/issues/494 |
| 06:33 | <rniwa_> | :( why are we keep finding all these new problems |
| 06:35 | <annevk> | rniwa_: because monkey patching doesn't really work in engineering... |
| 06:35 | <rniwa_> | @annevk: huh, we do monkey patching all the time and it works |
| 06:36 | <rniwa_> | @annevk: I think the problem here was that Google for the longest time worked on these specs on their own & also implemented things |
| 06:36 | <annevk> | rniwa_: we do? |
| 06:36 | <rniwa_> | @annevk: and they didn't benefit from having other vendors reading & verifying specs & implementations |
| 06:36 | <rniwa_> | @annevk: at my work that is re: monkey patching |
| 06:36 | <annevk> | rniwa_: sure, that's part of it too |
| 06:37 | <annevk> | rniwa_: maybe the definition we use in standards https://annevankesteren.nl/2014/02/monkey-patch differs from the definition Apple uses? |
| 06:40 | <MikeSmith> | TabAtkins or astearns or somebody, where is @supports defined? |
| 06:41 | <rniwa_> | @annevk: we run scripts after applying a patch to the script |
| 06:41 | <MikeSmith> | nm found https://drafts.csswg.org/css-conditional-3/#at-supports |
| 06:41 | <rniwa_> | @annevk: or at runtime, we override some other class's selectors in objective-c LOL |
| 06:41 | <annevk> | MikeSmith: aww, just found it too |
| 06:43 | <annevk> | rniwa_: yeah, I guess I'm saying that if you write standards that way, it's gonna suck |
| 06:43 | <MikeSmith> | annevk: yeah @supports seems like a handy feature |
| 12:17 | <Ms2ger> | annevk, you make a good point; thoughts on where to put it? |
| 12:20 | <annevk> | Ms2ger: I usually put it above the first instance if there's no good place |
| 12:20 | <annevk> | Ms2ger: also, use ", then ..." after if statements |
| 12:20 | <annevk> | Ms2ger: looked good to me otherwise |
| 12:22 | <Ms2ger> | Will do in a bit |
| 16:17 | <TabAtkins> | MikeSmith: For future help in finding where things are defined: https://drafts.csswg.org/indexes/ |
| 16:18 | MikeSmith | looks at https://drafts.csswg.org/indexes/ |
| 16:18 | <MikeSmith> | w00t |
| 16:18 | <MikeSmith> | TabAtkins: much thanks |
| 16:21 | <TabAtkins> | SimonSapin: Yes, SVG2 is the best reference. It's SVG1 plus new things minus dumb things and with some stuff rewritten to be better. |
| 16:54 | <AutomatedTester> | so Trump is the last GOP candidate... |
| 17:25 | <boogyman> | AutomatedTester: wrong channel |
| 17:25 | <AutomatedTester> | boogyman: so it is... |
| 17:26 | <AutomatedTester> | my bad |
| 17:26 | <AutomatedTester> | sorry all |
| 20:43 | <rniwa> | annevk: yt? |
| 20:44 | <rniwa> | Domenic: yt? |
| 20:45 | <Domenic> | rniwa: yep |
| 20:45 | <rniwa> | Domenic: what a shit show we're in :( |
| 20:45 | <Domenic> | yeah :( |
| 20:45 | <rniwa> | Domenic: TinyMCE 4.3.10 shipped with a wrong use of rootNode |
| 20:45 | <Domenic> | it's hard for me to understand why everything is breaking because of rootNode/deepPath |
| 20:45 | <Domenic> | what coding patterns are causing this |
| 20:45 | <Domenic> | ugh |
| 20:45 | <Domenic> | (i don't really want to know) |
| 20:45 | <rniwa> | Domenic: oh, doing if (event.deepPath) event.target = event.deepPath[0] |
| 20:46 | <rniwa> | Domenic: which is obviously undefined :( |
| 20:46 | <Domenic> | oh right the attribute to function switch |
| 20:46 | <Domenic> | i guess that's not completely crazy |
| 20:46 | <Domenic> | they're trying to feature test |
| 20:46 | <rniwa> | Domenic: I don't even know the point of that code because event.target would have that value anyway |
| 20:46 | <Domenic> | lol true |
| 20:46 | <rniwa> | Domenic: except nobody supported deepPath with v1 |
| 20:46 | <rniwa> | Domenic: as an attribute :( |
| 20:47 | <Domenic> | but in general code in the form `if (something.chromeSpecificAttribute) { use(something.chromeSpecificAttribute); }` is not crazy |
| 20:47 | <rniwa> | Domenic: so it seems that they were speculatively using the feature... |
| 20:47 | <rniwa> | Domenic: oh sure |
| 20:47 | <Domenic> | Ideally nobody writes chrome-specific code, but in the real world, people do |
| 20:47 | <Domenic> | flatPath or flattenedPath or whatever seems reasonable... |
| 20:48 | <Domenic> | or we just declare that from now on all new platform properties have to be symbols |
| 20:48 | <rniwa> | Domenic: I like piercingPath though |
| 20:48 | <Domenic> | hmm yeah that's pretty good. |
| 20:48 | <rniwa> | Domenic: flat is a bit misleading in the sense that it could contain unslotted contents for events. |
| 20:48 | <Domenic> | ah, i see |
| 20:49 | <rniwa> | Domenic: composedPath has the same issue I pose |
| 20:49 | <rniwa> | and I don't think we refer to "composition" anywhere else so that's also somewhat misleading |
| 20:49 | <Domenic> | introducing a new "piercing" concept is a bit annoying but if it's truly a new concept then it makes sense |
| 20:52 | <rniwa> | Domenic: well, we do still have shadow piercing combinators in dynamic profile of CSS selectors |
| 20:52 | <Domenic> | oh, true! |
| 20:52 | <Domenic> | that's nice |
| 20:53 | <rniwa> | Domenic: regardless of our opposition to the feature |
| 20:53 | <rniwa> | Domenic: the terminology seems to exist elsewhere |
| 21:22 | <Domenic> | terinjokes: robertkowalski: one of you want to fix https://github.com/whatwg/console/issues/54 ? should be a pretty simple IDL change :) |
| 21:24 | <terinjokes> | Domenic: making it now, was just revieiwng my GH notifications for today |
| 21:24 | <Domenic> | \o/ |
| 21:24 | <Domenic> | It's pretty sweet how this spec is actually making implementers start wanting to converge |
| 21:24 | <terinjokes> | yay! |
| 21:24 | <Domenic> | Not to mention getting unbound console methods |
| 21:25 | <Domenic> | i didn't think that was going to happen |
| 21:25 | <Domenic> | then all of a sudden chrome and webkit both are like 'yes let's do it, look at this long issue where people are asking if we can. we totally can.' |
| 21:27 | <terinjokes> | merged the PR for CoC. Forgot I had left that opened |
| 21:31 | <Domenic> | https://github.com/whatwg/console/issues/56 might make sense to fix too |
| 21:33 | <terinjokes> | i agree |
| 21:34 | <terinjokes> | Domenic: think i should open a PR for the IDL namespace change to, or hold off for now? |
| 21:34 | <Domenic> | terinjokes: so I think if you actually change the IDL it will break Bikeshed -_- |
| 21:35 | <terinjokes> | i meant add the note |
| 21:35 | <Domenic> | terinjokes: that was why I was thinking of a warning or something while I update IDL and then someone will update the Web IDL parser bikeshed uses and then bikeshed will update |
| 21:35 | <Domenic> | ah yeah |
| 21:35 | <Domenic> | go for it |
| 21:35 | <terinjokes> | wonder what various UAs do for missing labels in count |
| 21:36 | <Domenic> | good question |