Re: [css-gcpm] move inline/block decision to footnote area?

On 2/11/14 8:19 PM, "Alan Stearns" <> wrote:

>The current draft has Œfootnote¹ and Œinline-footnote¹ values for the
>float property, but this seems like a property of the footnote area more
>than each individual footnote.

I'd be interested in hearing more. This appears to be one of the
fundamental issues with footnotes‹are their properties determined mostly
by where they end up (footnote area) or what they are (elements with
float: footnote)?

I lean towards the former. It feels more direct, and I think would make it
easier to support multiple footnote areas in the future [1]. But that's
more a gut feeling than an actual argument.

>You mentioned on IRC that people do like to
>mix block and inline footnotes to save space, but that seems like an
>authoring nightmare to pick which footnotes are inline and which are
>What if there was a property you could set on the footnote area that took
>these values?
>block - footnotes are all display block
>inline - footnotes are all display inline
>inline-block - footnotes are all display inline-block, which means that a
>series of shorter footnotes would all render on a single line, while
>longer ones would render on their own.
>We might call the property display-inside, but I¹m not sure if adding
>inline and inline-block values to that particular property would be the
>correct thing to do.

I like the idea, but could it work on the footnote element itself rather
than the footnote area? That could address the authoring burden while
still allowing the option of footnote-by-footnote control. Håkon has
proposed a similar property [2], and so it might look like this:

span.footnote {
float: footnote;
footnote-display: compact; /* (or auto, or something, in addition to block
and inline) */





This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.

Received on Thursday, 6 March 2014 03:40:54 UTC