| 07:21 | <zcorpan> | Eric Portis (he/him): LGTM |
| 07:24 | <zcorpan> | I guess we should revive https://github.com/whatwg/html/pull/6695 cc Jake Archibald |
| 08:18 | <annevk> | Hmm, why does locking an issue restrict it to people with write access. That's kinda prohibitive. Would be nice if there was a "has engaged with this organization prior to this issue" variant. |
| 08:44 | <annevk> | Well, the XSLT issue is locked to people with write access unfortunately. Can't be reading that all day. |
| 10:58 | <Jake Archibald> | Hah, yeah. I'll get that PR up to date. |
| 12:03 | <Jake Archibald> | Filing my yearly-ish complaint about the HTML spec's wrapping making it hard to search |
| 12:04 | <jmdyck> | (I make myself a version without so many linebreaks, just for ease of searching.) |
| 12:19 | <keithamus> | annevk: writing tests now for styling of :heading(n), I'm confronted with: should the default styles for :heading(7..9) also be tweaked? We could simply set them to the same has :heading(6) or something? |
| 12:20 | <keithamus> | Feels weird that :heading(7) is now larger than :heading(6) |
| 12:22 | <annevk> | keithamus: ah, good point. Matching 6 seems reasonable, but not sure if that would violate some guidelines. |
| 12:22 | <zcorpan> | keithamus: maybe as part of adding headingoffset |
| 12:22 | <keithamus> | zcorpan: indeed |
| 12:23 | <annevk> | (Adding that attribute is what we're discussing.) |
| 12:25 | <keithamus> | AFAIK there aren't guidelines on the visual size of a heading, only that they are in order. Anything close to looking like a guideline for each heading only mentions h1-h6... so I think we may be in slightly uncharted territory |
| 12:32 | <zcorpan> | Making the text even smaller seems bad, it would be unreadable. Bold italic could work, but only gets us another level. Maybe alternating bold / bold+italic? Another thing for authors to "reset" though |
| 12:51 | <annevk> | keithamus: I suggest we keep them bold, but give them all the same margins and font-size as p. |
| 12:52 | <annevk> | keithamus: I guess this does raise the question as to whether we spell it :heading(7, 8, 9) or :heading(7), .... Meh. |
| 12:53 | <zcorpan> | n+7 |
| 12:53 | <keithamus> | I was going to hedge and spell it :heading(7), ... š |
| 12:54 | <keithamus> | :heading(7) is valid whether settle on <AnB> or <integer># so it skirts the whole discussion/conclusion |
| 12:54 | <annevk> | :nod: |
| 12:57 | <zcorpan> | Same as p matches no other heading style, but same font-size as :heading(4). Not sure that's better than matching :heading(6) |
| 13:04 | <annevk> | Oh, I didn't realize. Wow. None of those defaults are great then. |
| 13:13 | <Jake Archibald> | zcorpan: https://html.spec.whatwg.org/multipage/images.html#sizes-attributes - if I say "if element has a sizes attribute", would that be false if the element had a sizes attribute but the value was invalid? |
| 13:13 | <zcorpan> | Jake Archibald: no |
| 13:14 | <Jake Archibald> | I'm concerned about the "A sizes attribute is an attribute with requirements defined in this section." followed by "If present, the value must be a valid source size list." |
| 13:14 | <Jake Archibald> | So I was worried that it wouldn't 'have' one if it didn't meet the requirements |
| 13:15 | <zcorpan> | It's the DOM definition of attribute being present |
| 13:30 | <keithamus> | annevk: I think we also want Do I add headingReset getter steps or do I add additional steps in the computed level steps? |
| 13:47 | <Jake Archibald> | It feels like it shouldn't be getter steps, else el.headingReset = el.headingReset becomes weird |
| 13:48 | <Jake Archibald> | I wonder if it's a bit too magic in general. |
| 13:48 | <annevk> | Not sure that's a property we generally care about though. Hmm. |
| 13:49 | <keithamus> | I'm perfectly happy just adding something akin to or inclusiveAncestor is a dialog whose is modal is true |
| 13:49 | <annevk> | I think we generally make the getter compute the actual state if we can. |
| 13:50 | <annevk> | That does create weirdness for the case Jake mentions, but I think that's generally weird because we compute quite a bit. |
| 13:52 | <Jake Archibald> | Interesting. Which other cases of this exist? I know stuff like input.type = input.type can set the attribute to "text" even if it was absent or invalid, but that seems fine (the default isn't contextual). input.value = input.value has side-effects, butā¦ is that a good thing? document.cookie is a mess of course. |
| 13:53 | <Jake Archibald> | Eh, I guess you're right, you can't assume obj.prop = obj.prop is 'safe' on the web |
| 13:53 | <keithamus> | probably button.type which is contextual |
| 13:53 | <keithamus> | dialog.closedby also |
| 13:54 | <Jake Archibald> | Good points. Yeah, I formally retract my concern š |
| 13:55 | <Jake Archibald> | Given button.type, headingReset should be computed |
| 14:06 | <keithamus> | Here's with implicit font size of 1em for 7-9 |
| 14:06 | <keithamus> | html.css: |
| 14:10 | <annevk> | keithamus: that certainly has meme potential. Matching h6 is probably better then? (Or we don't support >6 in HTML, but I suspect that will also make people upset even though some (one?) screen readers reportedly treat >6 as 1.) |
| 14:15 | <keithamus> | yes I think so |
| 14:44 | <keithamus> | This all begs the question... <h> when?? |
| 14:47 | <Jake Archibald> | zcorpan: what do you think in terms of source.sizes if it has no sizes attr, but the related img does? |
| 14:52 | <keithamus> | so if dialog doesn't have a content attribute of headingreset, it can return true if is modal is true? |
| 14:52 | <keithamus> | But if it has a content attribute it must respect it? |
| 14:53 | <keithamus> | This is effectively the same though, as it's a boolean attribute - so the presence of it dictates is truthiness. I don't think you can set it to a value which would represent false? |
| 14:57 | <Jake Archibald> | Correct |
| 14:58 | <Jake Archibald> | In terms of spec, I'd write it as if modals force heading resetting |
| 17:42 | <annevk> | keithamus: it seems weird if it only resets while it's in the modal state because that means if you open it another way the headings would have a different level. |
| 17:42 | <annevk> | keithamus: that makes it effectively depend on an API call. I don't think that's good. |
| 17:43 | <keithamus> | keithamus: it seems weird if it only resets while it's in the modal state because that means if you open it another way the headings would have a different level. |
| 17:44 | <annevk> | I think we even have examples where calling both showModel and show are okay. It would be extremely confusing I think to have those end up with different heading levels. |
| 17:53 | <annevk> | We can discuss it, but I think it would be better if we don't add special heading reset semantics anywhere. Just make people request it explicitly as an expert feature. (Maybe if some element down the line clearly calls for it we can reconsider, but dialog in its current form isn't quite it I think.) |
| 17:56 | <keithamus> | We can discuss it, but I think it would be better if we don't add special heading reset semantics anywhere. Just make people request it explicitly as an expert feature. (Maybe if some element down the line clearly calls for it we can reconsider, but dialog in its current form isn't quite it I think.) I disagree. The headingreset attribute was precisely carved out for modals, which need to have an h1 title - I think this is actually a wcag recommendation IIRC. I think if there was ever an element that would have implicit headingreset, it would be a modal dialog. |
| 17:57 | <annevk> | But we don't have such an element. |
| 17:57 | <annevk> | And you can already use <h1> there if you need it. |
| 17:57 | <keithamus> | This is the point, you wonāt be able to. Youād have to manually add headingreset to your dialogs. |
| 17:59 | <annevk> | I could see adding it to dialog elements, period, but having heading levels depend on the state seems bad. |
| 18:00 | <keithamus> | I agree itās not nice but I donāt think either adding it to all dialogs, or not adding it to any, result in a better situation for users. |
| 18:01 | <keithamus> | If developers have to opt in to headingreset on modals then it becomes another thing that - if missed - becomes detrimental to users. If developers have to opt out by adding hesdinglevel=N it might negate the benefit of the feature (because theyād have to figure out the N which is sometimes not possible). |
| 18:03 | <annevk> | I think it's also bad for users if the outline of the document ends up shifting when they open a dialog. |
| 18:03 | <keithamus> | It does anyway. The entire page becomes inert. |
| 18:04 | <annevk> | That's an interaction thing. I'm talking about the semantics on which you might build new UIs and such. |
| 18:04 | <keithamus> | I think none of the options are great but IMO adding to just modals is confusing for developers but the best option for users. Adding to all dialogs by default is the worst option because itās wrong for users and difficult to workaround for users. If we really must then I suppose leaving it for the developer to add headingreset is better than forcing it all the time but it is a distant second imo. |
| 18:06 | <keithamus> | I donāt understand your point about semantics for new UIs. |
| 18:08 | <annevk> | I don't think the semantics of the document should change based on the state of a control. What :heading(x) matches should stay consistent throughout. |
| 20:32 | <Noam Rosenthal> | If you have the same <dialog> element that can be in both modal and non-modal state in the context of the same document, would you expect it to have different heading styles/behavior based on that modal state, or would the author put headingreset on that particular <dialog> so that both cases appear the same? |
| 20:33 | <Noam Rosenthal> | keithamus: ^ |
| 20:37 | <keithamus> | If you have the same |
| 20:37 | <keithamus> | If you have an example Iād love to see it. Not trying to skirt the question. |
| 20:38 | <keithamus> | But I suppose I would expect the heading structure to change. When modal itās effectively its own page so having a heading structure that starts at 1 so a user can āreach backā to the root heading could be useful. |
| 20:40 | <Noam Rosenthal> | hmm let's say you have a design system component for error notifications based on dialogs, with a <dialog id=error> element. Whether that dialog is shown in a modal way or not depends on which error it is and the context |
| 20:45 | <Noam Rosenthal> | I would find it surprising that showModal() changes things not to do with interactivity... but perhaps we can make this behavior feel a bit more explicit by having headingreset="when-modal" or "auto" or some such that hints that headingreset is a product of state |
| 21:00 | <Noam Rosenthal> | if this use case is not interesting and I always intend to use a particular <dialog> element as a modal, perhaps putting a headingreset on it is not a bad way to express an explicit intent of using it as a modal in the future |