Don’t rely on stacking contexts for marked content

[oraslaci]

Hi All,

I found an issue with PDF/UA where an inline element is put into a different stacking context because of {position: relative} and thus it's excluded the from the marked content tag in the content stream. To be more specific:

.reference {
    position: relative;
    top: -3px;
}
<p> Lorem ipsum <span class="reference">(i)</span> dolor</p>

Results in following structure:

I traced the issue back to this

    defines_stacking_context = (
        (style['position'] != 'static' and style['z_index'] != 'auto') or
        (box.is_grid_item and style['z_index'] != 'auto') or
        style['opacity'] < 1 or
        style['transform'] or  # 'transform: none' gives a "falsy" empty list
        style['overflow'] != 'visible')
    if defines_stacking_context:
        child_contexts.append(StackingContext.from_box(box, page))
        return

    stacking_classes = (boxes.InlineBlockBox, boxes.InlineFlexBox, boxes.InlineGridBox)
    if style['position'] != 'static':
        assert style['z_index'] == 'auto'
        # "Fake" context: sub-contexts will go in this `child_contexts` list.
        # Insert at the position before creating the sub-context.
        index = len(child_contexts)
        stacking_context = StackingContext.from_box(box, page, child_contexts)
        child_contexts.insert(index, stacking_context)

My question is why do we need the "Fake" context? Isn't position: static handled in the first part of the code? According to css specs, if z-index is auto, then there is no need for new stacking context.

Cheers and thanks for the awesome work, Laszlo.

[liZe]

Hi!

Thanks for the report. That’s a known problem we’re currently working on, as part of #2363. We should have great news soon!

[oraslaci]

Sounds awesome! Thanks! Looking forward!

[liZe]

If you’re interested in this issue, it’s time to test #2471! Feedback will be highly appreciated, even to say that it just works. 🙏