[specs notes] float-reference: inline

[JulieBlanc]

specification: https://css-print-lab.github.io/specs/notes-in-css-print/

We proposed float-reference: line for marginal notes, but I see that in the CSS Page Floats (working draft), they already propose lfloat-reference: inline`. That makes sense, and it seems logical to align with the CSS Page Floats proposal.

I've updated it accordingly, but what do you think?

This leads me to another question. In our proposal, we always place float-reference inside the @note-area.
For example:

@page {
    @note-area {
        content: element(sidenotes, all-once);
        float: top right;
        float-reference: page;
    }
}

note.sidenote {
    position: note(sidenotes);
}

However, for float-reference: inline, our examples placed it at the note level:

.marginal-note.note {
    position: note(marginal-note);
    float-reference: inline;
    padding-right: 10mm;
}

@page {
    @note-area {
        content: element(sidenotes, all-once);
        float: top left;
    }
}

With reflection, it seems more consistent to have float-reference: inline declared inside the @note-area, doesn't it?

But that brings us to another issue: what does the following example mean?

.marginal-note.note {
    position: note(marginal-note);
}

@page {
    @note-area {
        content: element(sidenotes, all-once);
        float: top left;
        float-reference: inline;
    }
}

This doesn’t seem logical, unless we say that float-reference: inline overrides the float: top values (left is still usefull).

If that's the case, it feels like, from a code perspective, float-reference: inline would effectively create multiple @note-area boxes. Which, incidentally, also happens with float-reference: column.

[Note that with all that, I now understand why they add float: bottom for @footnotes.]

[liZe]

If that's the case, it feels like, from a code perspective, float-reference: inline would effectively create multiple @note-area boxes. Which, incidentally, also happens with float-reference: column.

Yes. I think that float-reference should always be set on the element where float is set, to follow what’s in the Page Float specification. So, in our case, we always should have float and float-reference set in @note-area.

We’ll get a note area for each float reference:

• page: one for each page (footnotes as specified in GCPM are "just" a special case of this);
• column: one for each column;
• inline: one for each text line.

Setting float-reference in .note doesn’t mean anything, as .note is not a float.

As a consequence, example 7 can’t be achieved with the current code, we should use something like that instead:

@page {
    margin: 20mm 20mm 20mm 70mm;

    @note-area side {
        content: element(refs, all-once);
        float: left;
        float-reference: inline;
        margin-left: -50mm;
        width: 50mm;
    }
    @bottom-center {
        content: element(footnotes, all-once);
        width: 100%;
        vertical-align: bottom;
    }
}

note.refs {
    position: note(refs);
}

note.footnotes {
    position: note(footnotes); 
}

Does it make sense?

[liZe]

(And as the note areas are common inline floats, clear: left is a simple solution to avoid collisions.)

[JulieBlanc]

That was totally my thoughts too, float and float-reference should be in the same declaration.
It makes total sense, I'm going to replace it in the specifications.

@julientaq @grewn0uille what do you think? If you don't agree, we can always go back.

[JulieBlanc]

After a few tests, I discovered that the behaviour we're trying to describe works perfectly well with a simple float left on the notes themselves (span in my case) if we just add width, negative margin and clear properties.

Some screenshots.

With nothing, only span in text

With float: left

.float{
   float: left;
}

With float: left, clear, width and negative margin

.float

{
        float: left;
        clear: both; 
        width: 36ch; 
        margin-left: -42ch;
    }

Our proposal seems to duplicate the last example but makes our specification a little more coherent.

It seems to me that we add the idea that the @note-area should remain at page level, so if there are too many notes there needs to be a mechanism that says, "move the note to the next page" (which is what we proposed with note policy). However, there's nothing to say that the marginal note can be moved up if there's room above it.

It’s an other conversation but do we need to describe an algorithm for this case? I've put it as an issue in the notes but I think we can share it like that for the moment.

[julientaq]

if i understand correctly, in example 7 creates an implicit note-area for each note, which will be very complex to work with at specific places.

Let’s say you want to change the size and position of one specific note (something someone will do, because no one would :), i don’t see how we can do that without adding a custom @note-area for one specific note, while a float + clear-fix would be much more precise for free.

So, we could have something like

@page {
    @note-area {
        content: element(refs, all-once);
        float: left;
        float-reference: inline;         
    }
}

.note {
        margin-left: -50mm;
        width: 50mm;
        position: note(refs)
}

.note#note-with-an-img {
       margin-left: -90mm;
       width: 90mm;
}

then margin and width should be on the .note and note on the @note-area

But then, why would the float be added to the @note-area instead of the .note? nor any of all the other properties.

I’m not sure that we need to have @note-area for margin notes :think: we’d still need to have a note policy to define the page break, but maybe that’s enough?

[liZe]

After a few tests, I discovered that the behaviour we're trying to describe works perfectly well with a simple float left on the notes themselves (span in my case) if we just add width, negative margin and clear properties.

Yes, for simple cases. I realized that too when I wrote my last comment.

I’m not sure that we need to have @note-area for margin notes :think: we’d still need to have a note policy to define the page break, but maybe that’s enough?

I think that we still need a @note-area if we want notes to be put on the left on left pages and on the right on right pages, for example.

[JulieBlanc]

Let’s say you want to change the size and position of one specific note

It seems it's the same problem with other type of notes no ? 

I think it's possible to declare the width, margin, padding, etc. for both @note-page and the note itself.

This complements each other, @note-page is the note placement area, not the note itself. The same applies to sidenotes: @page-area is where sidenotes/footnotes/etc will be placed, but sidenotes/footnotes/etc remain independents nodes.

When I code sidenotes in javascript for the moment, I move them into a note area that has a specific size and is already placed in the page but I modify the sidenote blocks themselves too, with padding for example. It could just as easily be the size.  I think it's the same with marginal notes

We can achive your example with this code:

@page {
    @note-area {
        content: element(refs, all-once);
        float: left;
        float-reference: inline;    
        margin-left: -50mm;
        width: 50mm;     
    }
}

.note {
        position: note(refs);
}

.note#note-with-an-img {
       width: 90mm;
       position: relative;
      left: -30mm;
       overflow: visible;

}

This maintains the consistency of the specification and float-reference: inline; which is described in the page float specs.

In addition, note areas can have specific max-heights to help us with note policy (if notes overflow from the page). The only mechanism we don't have in other note types is the ability to “push up” the note when it overflows at the bottom of the page and there's room above it. Do we need a specific note policy for this case?

[liZe]

@JulieBlanc I 100% agree with your comment.

The only mechanism we don't have in other note types is the ability to “push up” the note when it overflows at the bottom of the page and there's room above it. Do we need a specific note policy for this case?

Or keep the feature for level 2? 😄

[julientaq]

It seems it's the same problem with other type of notes no ? 

I made a difference in my mind with margin notes and side note, but there is no difference aside from the table in the specs, aside from the table (https://css-print-lab.github.io/specs/notes-in-css-print/#types-of-notes). I understand your point.

One thing from your example ticks a bit @JulieBlanc. When you put the overflow: visible to the note, this wont override the note-area overflow property, but only the note you’re touching, and thus, wont make the note visible if the overflow of the note area is hidden.
And if you put the property to the note-areayou will affect all the notes without a possibility to override it specifically for a note.

We can assume that’s ok. but i’ll be curious to search for a better solution.

[julientaq]

@JulieBlanc I 100% agree with your comment.

The only mechanism we don't have in other note types is the ability to “push up” the note when it overflows at the bottom of the page and there's room above it. Do we need a specific note policy for this case?

Or keep the feature for level 2? 😄

isn’t that doable with css positionning?
Or do you mean when a note goes further down while there is still room on the page, so you move it up enough to be fully on the page ? did i understand correctly?

[liZe]

isn’t that doable with css positionning?
Or do you mean when a note goes further down while there is still room on the page, so you move it up enough to be fully on the page ? did i understand correctly?

I don’t think that it’s doable without adding an extra feature to the spec, and I’m suggesting that we can keep it for a later version.

[JulieBlanc]

One thing from your example ticks a bit @JulieBlanc. When you put the overflow: visible to the note, this wont override the note-area overflow property, but only the note you’re touching, and thus, wont make the note visible if the overflow of the note area is hidden.

The overflow: visible was a leftover from other code and is not needed. visible is the default for block elements, even on @note-area, so that should work.
We can't anticipate every exception, but we can make sure that exceptions can be added and that our proposal works with other CSS properties. And I believe our specifications are solid enough for that (except for the issue of marginal notes that push up, which we just discussed).

I don’t think that it’s doable without adding an extra feature to the spec, and I’m suggesting that we can keep it for a later version.

Agree. I also think we need other opinions, and there may be suggestions we haven’t thought of yet.