| 06:42 | <Domenic> | jwalden: from what I can tell in the specs that'll make its way down through fetch with no modifications to the `text/html` content-type, so it'll just enter the HTML parser's usual unknown charset logic, and thus probably windows-1252 for en-US. |
| 08:04 | <annevk> | Maybe we should make that fixed somehow for data: URLs |
| 13:35 | <TabAtkins> | Yeah, if we could patch that to utf-8 it would probably be fine? |
| 14:08 | <annevk> | I suspect windows-1252 would be safer |
| 14:10 | <TabAtkins> | Would it tho? HTML uses 1252 because of significant legacy content predating heavy utf-8 deployment. It's not immediately clear to me that data: urls would suffer from the same constraints. The 1252 default already breaks *modern* pages commonly, why wouldn't it break data: urls? |
| 14:11 | <annevk> | That's fair, I don't know for sure and given how URLs are parsed UTF-8 would make sense; I guess it'd require some research |
| 14:12 | <TabAtkins> | yeah |
| 14:13 | <TabAtkins> | also oh gosh, yes, i'm not even sure what it would mean for the url to be utf-8 encoded but contain html content that's 1252 encoded. |
| 14:22 | <zcorpan> | data:,å -> data:,%C3%A5 -> Ã¥ |
| 14:27 | <hsivonen> | data: URLs have been around for quite a long time, so there has been plenty of time for them to develop a dependency on the current behavior. |
| 14:33 | <gsnedders> | I mean an initial qusetion could be how many text/html data URLs contain non-ASCII |
| 14:44 | <hsivonen> | I'm not necessarily opposed to making data: default to UTF-8 if Chrome experiments with the compat fallout. I don't really have apetite for risking making Gecko the first mover on this one. |
| 14:46 | <hsivonen> | (OTOH, considering that HTML in data: is mainly for test cases, it's unclear that making it diverge from http: and https: serves the use case well.) |
| 19:04 | <jugglinmike> | It's not clear to me what is actually being displayed when an "inactive" drop-down-style <select> element is rendered. Is it simply the `<select>` element? Or is the `<select>` element acting as a container for the selected `<option>` element? |
| 19:07 | <TabAtkins> | Undefined. |
| 19:07 | <TabAtkins> | (intentionally, currently) |
| 19:07 | <TabAtkins> | Per CSS, <select> is a replaced element; it's a rectangle whose contents are completely opaque. |
| 19:08 | <jugglinmike> | TabAtkins thought so. Does that mean that styling <optgroup> and <option> is also undefined? |
| 19:08 | <TabAtkins> | Definitely. |
| 19:09 | <jugglinmike> | Well, that's a relief |
| 19:10 | <jugglinmike> | TabAtkins: think we can remove those from here: https://html.spec.whatwg.org/multipage/rendering.html#form-controls |
| 19:22 | <zcorpan> | jugglinmike: it's indeed currently undefined. But the values there are needed for web compat, and more should be added per https://github.com/whatwg/html/issues/1046 |
| 19:23 | <zcorpan> | jugglinmike: also, we should make it well-defined at least for appearance: none |
| 19:25 | <jugglinmike> | zcorpan: How can we standardize styling for elements whose rendering we intentionally do not standardize |
| 19:26 | <zcorpan> | it's a bit messy to try to make incremental improvements without a solid foundation, but I think for example the text-transform fix is a clear improvement even if it's still undefined what the effect of text-transform on <select> is, since browsers do allow it to have an effect |
| 19:26 | <jugglinmike> | Oh, I'm not suggesting we remove text-indent for `select` |
| 19:27 | <jugglinmike> | I want to remove `option` and `optgroup` |
| 19:28 | <jugglinmike> | since the effect of styling those is "definitely" undefined |
| 19:28 | <zcorpan> | <button> moved from intentionally undefined to intentionally defined in https://github.com/whatwg/html/pull/4143 :) |
| 19:29 | <TabAtkins> | A problem here is that what I just described is half-true. CSS officially is hands-off, but in practice some things *do* work in (most?) UAs. That's ocvered by that stylesheet. |
| 19:29 | <TabAtkins> | And we are *trying* to get to a point where CSS's interaction with form controls is well-defined. (Have been trying for at least twenty years.) |
| 19:29 | <TabAtkins> | (But actually maybe happening now.) |
| 19:31 | <jugglinmike> | That'd be great, and congrats on <button> |
| 19:32 | <zcorpan> | jugglinmike: "option, optgroup" should be removed because from the spec it doesn't match what what browsers have in their UA stylesheets |
| 19:32 | <jugglinmike> | Firefox does it |
| 19:33 | <jugglinmike> | https://dxr.mozilla.org/mozilla-central/rev/c909c105f914f69054b9a7c6b189ee39fa1cad44/layout/style/res/forms.css#354 |
| 19:33 | <jugglinmike> | https://dxr.mozilla.org/mozilla-central/rev/c909c105f914f69054b9a7c6b189ee39fa1cad44/layout/style/res/forms.css#388 |
| 19:34 | <zcorpan> | Ah. I stand corrected. So that's different from webkit/chromium |
| 19:34 | <jugglinmike> | yeah... |
| 19:34 | <jugglinmike> | I can appreciate that we're trying to define form controls |
| 19:34 | <jugglinmike> | Especially in the presence of `appearance: none` |
| 19:36 | <jugglinmike> | but I also think consistency is important. The spec currently seems internally inconsistent because it leaves this area as implementation defined but also specifies parts of it |
| 19:38 | <jugglinmike> | Also, is there any text that explains the spec's contours around form controls? |
| 19:39 | <jugglinmike> | I'm going to close https://github.com/whatwg/html/issues/4675, and I'd like to cite something if possible |
| 19:40 | <zcorpan> | You're right that it's inconsistent, and this is not really explained in the spec I think. We could add a note about it. |
| 19:42 | <zcorpan> | But technically, the rules in the rendering section are just expected to be in the UA stylesheet, and the effect should be as per CSS rules. If CSS rules says any CSS property's behavior is undefined for a particular element, then that just means that it's undefined |
| 19:42 | <zcorpan> | You can still check what is in the UA stylesheet with getComputedStyle |
| 19:43 | <jugglinmike> | I could, but the value of doing so seems questionable |
| 19:44 | <zcorpan> | Baby steps towards the end goal of having defined & interoperable form controls rendering :) |
| 19:46 | <zcorpan> | in particular, if something (like text-transform on select) is wasting web developers' time, and adding a property to the UA stylesheet in one browser fixes it, then we can specify and test that without waiting for rendering rules of <select> to be defined |
| 19:46 | <zcorpan> | In the case of text-indent of option, I don't know if it's an important interop issue or not |
| 19:47 | <jugglinmike> | Agreed. And we have evidence (in the form of "CSS normalizer" projects) that text-transform on select is wasting web developers' time |
| 19:47 | <zcorpan> | Removing option/optgroup and leaving a spec issue open to investigate seems reasonable |
| 19:48 | <zcorpan> | But leaving it as-is and having the issue also seems reasonable |
| 19:49 | <jugglinmike> | I'd be comfortable leaving it as-is if the new issue were referenced in the specification |
| 19:50 | <jugglinmike> | It'd still be inconsistent, but at least the inconsistency would be obvious |
| 19:50 | <zcorpan> | Sure |
| 19:56 | <jugglinmike> | zcorpan: still, I don't think I can report this issue |
| 19:56 | <jugglinmike> | due to my unfamiliarity with the problem |
| 19:57 | <zcorpan> | jugglinmike: OK, I can report it |
| 19:57 | <jugglinmike> | Even just limited to the <select> element, I can't say what we can/should standardize |
| 19:58 | <zcorpan> | Yeah, I don't know that either. <select> is pretty complex though |
| 19:58 | <zcorpan> | Things like buttons and checkboxes are simpler |
| 20:19 | <jugglinmike> | zcorpan: doesn't match what webkit-derived browsers have in their stylesheets |
| 20:19 | <jugglinmike> | oops, ignore that zcorpan |
| 20:33 | <zcorpan> | jugglinmike: https://github.com/whatwg/html/issues/4676 |
| 20:39 | <oliverdunk> | zcorpan: I don't know if this is relevant to what you're discussing, but I'm currently looking into letting option elements increment CSS counters in Chrome |
| 20:41 | <zcorpan> | oliverdunk: interesting! It's relevant for the discussion of what the effect of CSS is on form controls, though myself and jugglinmike haven't looked at counters |
| 20:41 | <zcorpan> | oliverdunk: what's the motivation? |
| 20:44 | <oliverdunk> | zcorpan: My only association is that I wanted to make a contribution to Chromium, and found this bug as one to try: https://bugs.chromium.org/p/chromium/issues/detail?id=799465 |
| 20:45 | <oliverdunk> | The use case is letting a changed select input alter a counter value: https://codepen.io/kizu/pen/PEJgpr |
| 20:45 | <jugglinmike> | I didn't know CSS counters existed |
| 20:45 | <TabAtkins> | oliverdunk: I'm curious about the motivation too. ^_^ Blink implements CSS counters in a broken hacky way on the box tree; they're *specified* to work over the element tree (but pay attention to whether the element generates a box or not). That all said, since option/optgroup aren't rendered by CSS, it's not clear whether they "generate a box" or not, and thus whether they should increment counters or not. |
| 20:45 | <TabAtkins> | Probably if you do a strict reading, they don't generate boxes, and so shouldn't increment counters. |
| 20:46 | <oliverdunk> | Interesting TabAtkins. I suspect you know a lot more than me, I just assumed from the bug that implementing them was right. |
| 20:47 | <TabAtkins> | I wrote the spec for counters. ^_^ |
| 20:47 | <oliverdunk> | In that case, you _definitely_ know a lot more than me! |
| 20:47 | <oliverdunk> | Forgive my ignorance :P |
| 20:47 | <TabAtkins> | But whether the spec is describing the ideal reality, compared with current browser impls, is unclear. And the ideal interaction of replaced-element descendants and counters definitely wasn't explicitly considered. |
| 20:48 | <TabAtkins> | I"ll open an issue in csswg |
| 20:50 | <TabAtkins> | oliverdunk: Does that code currently work in any browser? |
| 20:51 | <oliverdunk> | TabAtkins: definitely Firefox, and apparently the old Edge. |
| 20:54 | <TabAtkins> | https://github.com/w3c/csswg-drafts/issues/4004 |
| 20:58 | <oliverdunk> | TabAtkins: Thanks! Out of interest, when you say "rendered by CSS", does that just mean if CSS applies or not? |
| 21:07 | <TabAtkins> | I mean "rendering is fully explained by the CSS box model". |
| 21:07 | <TabAtkins> | option/optgroup aren't explained at all by CSS currently. |
| 21:15 | <oliverdunk> | TabAtkins: Gotcha. Once a decision is made on that bug, assuming the changes aren't too major, I'd love to try making them. |