[css-inline] Should dominant-baseline inherit?

[ewilligers]

We have inconsistencies between specifications and between implementations.

It isn't clear if dominant-baseline was intentionally made inherited when it moved from SVG to CSS Inline 3, or if this change was accidental during transcription.

https://www.w3.org/TR/css-inline-3/#propdef-dominant-baseline
Inherited: yes

commit 107993abb5a370cb1fb7d343a2bb93c4d4cc3135
Author: fantasai <fantasai.cvs@inkedblade.net>
Date:   Wed Feb 11 07:01:56 2015 -0500
[css-inline] Draft vertical-align stuff imported from SVG.

https://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty

Inherited: no

https://svgwg.org/svg2-draft/propidx.html

"This appendix is informative, not normative."
Name, Inh.
dominant-baseline, no

https://drafts.csswg.org/css-writing-modes-3/#baseline-alignment
talks about parent’s dominant baseline and child’s dominant baseline.

Blink: does inherit

https://codereview.chromium.org/1241163002 (2015)
Update dominant-baseline property as inheritable property
as per spec.
http://dev.w3.org/csswg/css-inline/#dominant-baseline

Edge: does not inherit
Firefox: does not inherit
Safari: does not inherit

[tabatkins]

Almost certainly a mistake, there's no reason we'd have changed this during the port, that would break things.

[tabatkins]

@fantasai Just to confirm, this was a mistake, right? Easy fix if so.

[fantasai]

dominant-baseline should definitely inherit. Otherwise it would reset itself to the initial value every time someone introduces a <span> or <a>!

And then you couldn't set it on a document and expect it to take effect across the entire thing, properly excepting sections which need a different dominant-baseline.

The change was deliberate. The SVG1.1 initial value has more magic than ours: it behaves like inherit, but only when you set it on a descendant of a <text> element. You can get away with that model if you don't have much structure, as SVG1.1 text doesn't, but it is unworkable in a structured document markup language like HTML. Hence the change to simplify auto and make the property actually inherit.

[fantasai]

Agenda+ to bring this to the attention of the rest of the WG. CC @AmeliaBR

[css-meeting-bot]

The Working Group just discussed Should dominant-baseline inherit?, and agreed to the following:

• RESOLVED: Close this issue with no change to CSS Inline

The full IRC log of that discussion

<dael> Topic: Should dominant-baseline inherit?
<dael> github: https://github.com//issues/2926
<dael> fantasai: I don't remember if we resolved on this, but it's really the only reasonable thing. As spec in SVG this has an auto value that behaves like inherit but only on a text element.
<chris> q+
<dael> fantasai: Seems awk design that's a result of not thinking about inheritence. CSS inline L3 spec that dom-baseline is inherited value
<dael> fantasai: Wanted to ask for review and confirm
<astearns> ack chris
<dael> chris: This isn't so much inheritence it was more that once you started a text run the font you set on that effected kinda like underline when it effects the children. But if you can make it work using inheritence fine, but that's why originally
<dael> fantasai: CSS modal I think we should use works that each element has a dom-baseline property generally same as parent and that sets baseline to align own contents. When align to parent uses alignment baseline which is different prop. I don't see need to inherit.
<chris> ok, sounds good
<dael> fantasai: If you want a baseline table that passes through changes in font size etc to descendants I can see case for more complex, but I don't think that's deisred. I think you want a localized baseline grid and then that whole thing aligns to parent baseline table. Then you don't pass baseline through multiple elements
<dael> chris: Fine to me
<dael> fantasai: Okay
<dael> astearns: Any concern that 3 engines aren't making prop inheritable?
<dael> fantasai: In SVG context the inheritence will be archine. I don't think most people will set on root SVG element. Once on text element it does inherit. I don't think anyone is chaning OM value of dom baseline of a text element in SVG. IN general case behavior is identical. Weird cases for a change and I don't expect them to be common
<dael> fantasai: That's my expection, could be wrong
<fantasai> s/archine/arcane/
<dael> astearns: ericwilligers are you okay having dom baseline inherit?
<dael> ericwilligers: Fine with it. It's what blink does. I can send a PR for SVG spec to mention it's inherited
<dael> fantasai: Also need to change auto value so it doens't pretend to inherit
<dael> astearns: Anything else on this?/
<dael> astearns: Prop: Close this issue with no change to CSS Inline
<dael> astearns: Objections?
<dael> myles: Reset what dom baseline is at writing mode change?
<dael> fantasai: At writing mode change the dom baseline also changes.
<dael> myles: Isn't that what auto means? If someone sets to another value you want to change at writing mode change
<dael> fantasai: That is an interesting idea. Don't know that it's strictly necessary. I think you could argue you might want that to happen, but it depends on writing system.
<dael> fantasai: If you have inline block with horz text you would want it not to have central baseline in a vertical doc
<dael> florian: Some kind of expanded version of dom baseline with two values?
<dael> myles: No, not that. I think current behavior allows for this
<dael> fantasai: Currently initial value is auto and doesn't resolve to anything. If you set to a different baseline it inherits through orthogonal flow. For default case, that's typical for Japanese or Chinese because it does the right thing
<dael> myles: I'm not sure saying auto works correctly means property is correct. Maybe a new issue?
<dael> astearns: I was thinking new issue, but now I'm thinking that if we do take from SVG that dominant doesn't inherit we can have auto do the right thing. We're taking on complexity of auto to solve a writing mode switch
<dael> fantasai: But when you switch writing modes and you set something like mathematical baseline what do you expect at a writing mode change? If what you want is to have alphabetic in horz and central in vertical set to auto and it works. If you set to mathematical baseline what do we propose to do other than mathematical. If it's the same as before the writing mode change that's inherit
<dael> astearns: I suggest we define auto somewhat like SVG where auto takes dom baseline of parent unless writing mode change and if writing mode change auto takes standard baseline for writing mode
<dael> myles: Different. I was thinking that any value for dom baseline would apply to all descendants until a triggering condition makes it not apply
<dael> fantasai: What does not apply mean?
<dael> myles: On other side of trigger it resets to auto
<dael> fantasai: I don't think that is nec what you want. I don't think it's worth the complexity to make this non-inherit. That would be confusing because auto would have to look deep in document trees if you set inside a root. You have to go up the tree every time.
<chris> q+
<dael> fantasai: And what would we gain? I don't think anything because I don't think switching is always the right call. When we want the writing mode to trigger a change in dominant is switch between alpahetic or cental and auto will do the switch. Unless you set it to something else it will have that behavior. I don't think resetting it is nec/ the right answer
<dael> fantasai: No one has given me a clear use case where writing modes should trigger a change in dom baseline except what's covered in auto. Unless there's another use case it's not worth doing
<dael> dbaron: Is norm for Hindi and other languages that you'd want to set dom baseline to hanging?
<dael> astearns: no b/c fonts don't support. Indic uses another baseline
<dael> myles: [missed] If you're using web fonts and you know it supports you should
<dael> dbaron: If you're saying this work auto if for vertical Chinese in a Hinid doc it doesn't work then it doesn't.
<astearns> s/Indic uses another/Indic uses alphabetic/
<dael> chris: To dbaron not all fonts support all baselines and it's more a case that an occational one does support. myles spoke about triggering conditions, which are other triggering conditions? If it's just that one perhaps the 2 values florian suggested would be better?
<dael> myles: I don't know on other triggering. I haven't don research. one prop with 2 values seems a lot of added complexity.
<dael> fantasai: dbaron your case when switching Indic to Chinese when you haev a writing system change you want a baseline change. Horz Chinese in an Indic doc you'd want Chinese to have own dominent baseline. That's a writing system change, not a writing mode change. Writing mode isn't trigger you're looking for. Indic doc with hanging baseline and both horz and vert text would you switch dom baseline for vert indic text would you switch? I don't htink so.
<dbaron> fantasai, that makes sense to me
<dael> astearns: I haven't heard anything that makes me thing we would keep dom baseline from inheriting. I think we should open a new issue for these switches and what happens. Is everyone okay leaving this to another issue and close this one?
<dael> myles: Fine
<dael> astearns: Everyone was interested, but it would be good to have this as an issue.
<fantasai> propsed resolution: No change to css-inline, dominant-baseline inherits and auto only switches between alphabetic/central (not synthesizing inheritance)
<dael> florian: Fine. We can expore 2 value eslewhere
<dael> astearns: Objections to Close this issue with no change to CSS Inline
<dael> astearns: ?
<dael> RESOLVED: Close this issue with no change to CSS Inline