| 04:17 | <MikeSmith> | so I am planning to spend some time next week doing an experimental implementation of a language-detection feature for the HTML checker |
| 04:18 | <MikeSmith> | but I am wondering what methodology to use for getting the best sample of text from a document to check in the normal case |
| 04:19 | <MikeSmith> | general case |
| 04:19 | <MikeSmith> | it seems clear I want to begin but only looking at some text from some point in the body |
| 04:19 | <MikeSmith> | ignoring the head |
| 04:20 | <MikeSmith> | and ignoring any text nodes from <script> |
| 04:21 | <MikeSmith> | but if I do the naive thing of just looking at the first couple thousand characters of a given document, it many cases that is just going to amount to looking at at Table of Contents or some such |
| 04:23 | <MikeSmith> | which will actually probably work fine in practice as far as identifying the language of the document, but then my implementation amounts to being a more specific language-identification-by-only-looking-at-front-matter tool |
| 04:24 | <MikeSmith> | so I am wondering if there are better heuristics for detecting when I have hit the actual main text flow of a document |
| 04:26 | <MikeSmith> | btw this needs to not introduce a requirement significantly increasing the amount of memory the checker uses, so I can’t do the really simple thing of just sucking the whole document and running the language detector on the whole doc |
| 04:28 | <MikeSmith> | one simple idea is just to not start collecting any characters to check until I hit the first <p> |
| 04:31 | <MikeSmith> | another is to not do it until I hit the first h2 or h3 or h4 |
| 10:09 | <howdoi> | wasup with Array.prototype.values? |
| 10:09 | <howdoi> | String.prototype.contains also had issues right? |
| 10:10 | <mathiasbynens> | howdoi: yeah, so it was renamed to `includes` |
| 10:10 | <howdoi> | mathiasbynens: reason being? |
| 10:11 | <howdoi> | not a security thinge right? |
| 10:11 | <mathiasbynens> | howdoi: not web-compatible https://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web-compatible |
| 10:11 | <howdoi> | it broke some other code AFAIR |
| 10:11 | <howdoi> | MooTools! Thanks I remember reading that mathiasbynens |
| 10:11 | <howdoi> | that was fast! |
| 10:12 | <howdoi> | and with values, what's the issue? |
| 10:12 | <howdoi> | we don't even need .values(), for-in does a good job |
| 10:13 | <howdoi> | or even Symbol.iterator |
| 10:13 | <mathiasbynens> | howdoi: see https://bugs.chromium.org/p/v8/issues/detail?id=4247#c12 which points to https://bugs.chromium.org/p/chromium/issues/detail?id=615873 |
| 10:16 | <howdoi> | mathiasbynens: Array.values would have been better? |
| 10:34 | <mathiasbynens> | howdoi: who knows |
| 10:34 | <howdoi> | :{ |
| 12:29 | <Greg_> | Hello |
| 16:02 | <AutomatedTester> | annevk: is there a list of idl attributes that are not element attributes anywhere? |
| 16:08 | <Ms2ger> | "all of them"? :)( |
| 16:09 | <Domenic> | AutomatedTester: assuming you mean "IDL attributes that don't reflect element attributes", there's not yet, but you could get reasonably close by excluding those with [CEReactions] |
| 16:10 | <Domenic> | That will exclude some that should be included, since [CEReactions] really means "can modify the DOM in certain ways". But everything that is a reflected attribute will have [CEReactions]. |
| 16:11 | <AutomatedTester> | Domenic: ahh cool |
| 16:11 | <AutomatedTester> | Domenic: I can see those in the html spec |
| 16:11 | <AutomatedTester> | I will make a list |
| 16:12 | <Domenic> | One day we will spec [Reflect] |
| 16:12 | <AutomatedTester> | Domenic: wrt to WebComponents, how would Reflect work |
| 16:12 | <Domenic> | AutomatedTester: what do you mean exactly |
| 16:13 | <Domenic> | [Reflect] would just be a way of expressing in IDL the spec's current "The target IDL attribute must reflect the content attribute of the same name." |
| 16:13 | <AutomatedTester> | Domenic: normal reflective attributes do not need to be reflective in web components iirc |
| 16:13 | <Domenic> | It's fairly unrelated to web components |
| 16:13 | <Domenic> | Web components can create whatever API they want |
| 16:13 | <Domenic> | Good ones will, IMO, have APIs that reflect their valid attributes |
| 16:13 | <Domenic> | but that'd be done manually |
| 20:13 | <TabAtkins> | Mek: Looks like the problem should be fixed? Domenic, you too. |
| 20:14 | <TabAtkins> | lmk if there are still refs missing. |
| 20:39 | <Mek> | TabAtkins: yeah, looks fixed |
| 21:22 | <wanderview> | love the broken emoji in this tweet https://twitter.com/webkit/status/746441587811508227 |
| 21:22 | <wanderview> | at least on my machine/platform |
| 21:23 | <nox> | wanderview: It works on Apple computer, it's a private use code point. |
| 21:23 | <nox> | wanderview: It's Apple's logo. |
| 21:23 | <wanderview> | yea, thats what I was guessing |
| 21:23 | <wanderview> | just drives the point home, I guess |