| 16:17 | <annevk> | JakeA: (and others interested in better defining storage APIs) https://github.com/whatwg/storage/issues/18#issuecomment-614751336 |
| 16:37 | <FND> | hi, I just noticed that `customElements.whenDefined(node.nodeName)` seems invalid in both Firefox and Chrome due to `nodeName` using uppercase letters |
| 16:37 | <FND> | is that intentional? I couldn't find any details on name restrictions other than hyphenation |
| 16:38 | <annevk> | FND: looks intentional and makes some sense given XML |
| 16:38 | <annevk> | FND: you could do node.localName |
| 16:40 | <FND> | MDN says use of localName is discouraged? |
| 16:40 | <FND> | (I'm an old-man wannabe, so quirksmode.org has ingrained `nodeName` in my mind) |
| 16:41 | <FND> | but I could easily go with `.toLowerCase()`, I was just wondering why custom elements make this distinction when AFAIK other DOM APIs are case-insensitive |
| 16:46 | <Domenic> | Wow, MDN is very wrong |
| 16:47 | <Domenic> | localName is encouraged, nodeName is discouraged |
| 16:47 | <annevk> | FND: MDN is misguided then... (toLowerCase() is fraught and might do the wrong thing for non-ASCII code points) |
| 16:47 | <Domenic> | I don't see anything in https://developer.mozilla.org/en-US/docs/Web/API/Element/localName |
| 16:47 | <FND> | ah, I was looking at Node.localName, not Element.localName |
| 16:47 | <FND> | https://developer.mozilla.org/en-US/docs/Web/API/Node/localName |
| 16:48 | <Domenic> | Hmm, I see, that's confusing... but I'm not sure what to concretely suggest MDN do |
| 16:48 | <FND> | yeah, the Node vs. Element thing is often confusing... |
| 16:49 | <FND> | anyway, TIL localName is preferred - thanks! |
| 16:50 | <FND> | yet my original puzzlement remains: why is the custom-elements API case-sensitive? am I wrong in thinking all/most other DOM APIs are case-insensitive? |
| 16:51 | <annevk> | FND: a lot are ASCII case-insensitive sometimes, with newer APIs we try to be a bit stricter so there's less of a difference between HTML and XML documents |
| 16:51 | <annevk> | FND: as the core model is very much case-sensitive |
| 16:52 | <FND> | roger, good to know - and yeah, ASCII assumptions is a good point |
| 16:57 | <FND> | jobs |
| 16:57 | <FND> | fg |
| 16:57 | <FND> | oops, sorry |
| 21:52 | <justJanne> | So there's an open question which is kind of interesting |
| 21:52 | <justJanne> | If a web notification is spawned with a body of "text <b>foo</b> bar" |
| 21:52 | <justJanne> | Should the browser escape this, or not? |
| 21:52 | <justJanne> | Firefox doesn't escape it on certain platforms, leading to the body text being interpreted as markup by the system notifications |
| 21:53 | <justJanne> | Chrome always escapes it, and on Windows also all browsers escape it |
| 21:53 | <justJanne> | Leading to a handful of edge cases where it becomes "text foo bar" instead of "text <b>foo</b> bar" |
| 21:54 | <justJanne> | In this case it's interesting because a notification with a body containing "<" led to the second half of the body disappearing, due to the native notification system interpreting it as malformed markup |
| 21:54 | <justJanne> | Is this a bug in Firefox or the webapp? |
| 22:12 | <Krinkle> | justJanne: I'm not entirely sure about the escaping part, but I do know that afaik web notifications do require that notifications can be rendered as plain text, so it's definitely true that it can't require HTML-escaped input in a way that promises to render them. The question is, how can you tell the browser that is already plain text or that it's marked up with HTML the browser shoudl strip if needed. |
| 22:14 | <Krinkle> | from looking at the spec, I see no mention of HTML support. so I would guess it is meant to be plain text, there is no markup support beyond that "title" and "icon" stand separate from "body" (often with title being bold). |
| 22:15 | <Krinkle> | and given no primitive in the browser for easily escaping plain text, I imagine it's not intended that developers escape it themselves |
| 22:16 | <Krinkle> | Probably a bug in firefox on non-Windows then? |
| 22:17 | <Krinkle> | OK, the spec mentions \n as being a paragraph boundary, so yeah, definitely plain text and not HTML. |
| 23:01 | <TabAtkins> | Ugh, "plain text only" is discriminatory against languages that need some degree of markup. Common English-speaking programmer mistake, tho. |