/irc-logs / w3c / #css / 2013-03-19 / end

Options:

# Session Start: Tue Mar 19 00:00:00 2013
# Session Ident: #css
# [00:06] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [00:06] * Joins: cabanier (~cabanier@public.cloak)
# [00:10] <fantasai> TabAtkins_: http://wiki.csswg.org/spec/levels
# [00:13] * Joins: macpherson (~macpherson@public.cloak)
# [00:16] * Quits: abucur (~abucur@public.cloak) ("Leaving")
# [00:30] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [00:34] * Quits: lmclister (~lmclister@public.cloak) ("")
# [00:55] * Joins: shanestephens (~shanestephens@public.cloak)
# [00:56] * Quits: shanestephens (~shanestephens@public.cloak) (Client closed connection)
# [00:56] * Joins: shanestephens_ (~shanestephens@public.cloak)
# [00:57] * shanestephens_ is now known as shanestephens
# [00:58] * Joins: shanestephens_ (~shanestephens@public.cloak)
# [01:00] * Quits: shanestephens (~shanestephens@public.cloak) (Ping timeout: 60 seconds)
# [01:00] * shanestephens_ is now known as shanestephens
# [01:05] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [01:05] * Joins: krit (~krit@public.cloak)
# [01:06] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [01:13] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [01:16] * Quits: shanestephens (~shanestephens@public.cloak) (shanestephens)
# [01:23] * Joins: dbaron (~dbaron@public.cloak)
# [01:37] * Joins: shanestephens (~shanestephens@public.cloak)
# [01:50] <fantasai> dbaron++
# [01:50] <dbaron> for? :-)
# [01:51] <fantasai> Sending such a clearly explaiend and detailed email of the transition/animations cascade problem :P
# [01:56] * leaverou is now known as leaverou_away
# [01:56] <dbaron> I think I probably omitted at least half the story, but anyway...
# [02:00] * leaverou_away is now known as leaverou
# [02:02] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:03] * Quits: shanestephens (~shanestephens@public.cloak) (shanestephens)
# [02:13] * Quits: macpherson (~macpherson@public.cloak) ("This computer has gone to sleep")
# [02:22] * Joins: macpherson (~macpherson@public.cloak)
# [02:24] * Quits: macpherson (~macpherson@public.cloak) ("This computer has gone to sleep")
# [02:27] * leaverou is now known as leaverou_away
# [02:34] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [02:34] * Joins: rhauck (~Adium@public.cloak)
# [02:38] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [03:02] * Joins: rhauck (~Adium@public.cloak)
# [03:03] * Joins: rhauck1 (~Adium@public.cloak)
# [03:07] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [04:01] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [04:03] * Joins: macpherson (~macpherson@public.cloak)
# [04:05] * Quits: macpherson (~macpherson@public.cloak) ("This computer has gone to sleep")
# [04:10] * Joins: shanestephens (~shanestephens@public.cloak)
# [04:34] * Joins: cabanier (~cabanier@public.cloak)
# [04:40] * Joins: macpherson (~macpherson@public.cloak)
# [04:53] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [04:55] * Quits: shanestephens (~shanestephens@public.cloak) (shanestephens)
# [04:56] * Joins: shanestephens (~shanestephens@public.cloak)
# [04:57] * Quits: macpherson (~macpherson@public.cloak) ("This computer has gone to sleep")
# [04:59] * Quits: shanestephens (~shanestephens@public.cloak) (shanestephens)
# [06:29] * Joins: macpherson (~macpherson@public.cloak)
# [06:31] * Quits: macpherson (~macpherson@public.cloak) ("This computer has gone to sleep")
# [07:00] * Joins: SimonSapin (~simon@public.cloak)
# [07:24] * Joins: shanestephens (~shanestephens@public.cloak)
# [07:29] * Quits: shanestephens (~shanestephens@public.cloak) (shanestephens)
# [07:55] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [08:42] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:49] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [08:58] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:01] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [09:03] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:03] * Quits: Ms2ger (~Ms2ger@public.cloak) ("Leaving")
# [09:03] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:10] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [09:24] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:40] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [09:42] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [09:55] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:03] * Joins: SimonSapin (~simon@public.cloak)
# [10:11] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [10:25] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:41] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 60 seconds)
# [10:55] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [11:01] * Joins: pjrm (~pjrm@public.cloak)
# [11:02] * leaverou_away is now known as leaverou
# [11:12] <pjrm> SimonSapin: Re default z-ordering of page-margin boxes: I was drafting a reply to the proposal, but didn't finish it before it was already resolved to adopt it. So this is probably too late, but I'll write a bit anyway.
# [11:13] <pjrm> The premise for adopting an arbitrary ordering was that there's no single ordering that would make sense for all 'direction' and writing mode values.
# [11:13] <pjrm> I was wondering what if we did make it conditional on root's direction & writing-mode.
# [11:13] <SimonSapin> pjrm: it’s not too late. We resolved on picking *something* but there was no strong proposal on what the order should be
# [11:14] <SimonSapin> That’s doable. What would be the exact order?
# [11:15] <pjrm> The order I currently use for lr-tb is top boxes (including corners) in left-to-right order, then bottom boxes (including corners), then remaining left boxes, then remaining right boxes.
# [11:16] <pjrm> It's still fairly arbitrary, but it's still a bit less likely to cause surprises than a completely arbitrary order.
# [11:16] <SimonSapin> Although I don’t think too much complexity there (vs. a fixed order) is worth it. These boxes should really not overlap anyway, and complex cases can be handled with z-index
# [11:17] <SimonSapin> It remains to judge how much is too much complexity
# [11:17] <pjrm> I was just about to say: Given that 'z-order' for margin boxes is now mandatory, I think implementation difficulty doesn't change much.
# [11:18] <pjrm> I should say, I don't have a strong preference between the constant clockwise order or the direction-dependent ordering;
# [11:18] <pjrm> this is just an alternative that I was going to submit to be considered along with the clockwise proposal.
# [11:18] <SimonSapin> why bottom before left/right?
# [11:19] <pjrm> My thought was that side boxes are special compared to headers & footers, and that it's more important to see side boxes than headers & footers.
# [11:19] <pjrm> headers & footers are more likely to have reader-predictable content, was my thought.
# [11:20] <SimonSapin> ok
# [11:20] <SimonSapin> as long as it’s defined, I don’t have a strong opinion on what the order should be
# [11:25] <SimonSapin> pjrm: feel free to write up a proposal on www-style, I’ll bring it up on the next conf call
# [11:25] <SimonSapin> also, is it based on direction/writing-mode on the root element or of the page?
# [11:26] <pjrm> I hadn't considered that possibility, actually. Do those properties apply to the page context?
# [11:27] <SimonSapin> direction is in http://dev.w3.org/csswg/css3-page/#page-property-list , writing-mode is undefined (not in css 2.1)
# [11:27] <SimonSapin> but they can
# [11:27] <SimonSapin> this list needs work anyway
# [11:28] <pjrm> yes, if direction is there, then it probably makes sense to allow writing-mode too.
# [11:28] <pjrm> But yes, the page context values (which inherit by default from root values) would make more sense if they do apply in page context.
# [11:30] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [11:30] <SimonSapin> we’re discussing changing back @page to *not* inherit from the root. It could be the "least worse" to break the definition cycle with viewport units, but I’m not even sure yet it’s enough
# [11:31] <SimonSapin> consider :root{font-size: 1vw} @page {width: 50em}
# [11:32] <pjrm> There was also a proposal not to allow vw units for (at least some) page contexts. E.g. because different pages can have different widths, so the choice of which page you take vw from is somewhat arbitrary and may well not do the right thing on other pages.
# [11:33] <pjrm> (Actually, I think I'm just guessing at what the proposal was from a subject line, i don't think i've actually read the proposal of that message yet...)
# [11:34] <pjrm> I seem to remember that inheriting from root was a good solution for things like font-size, among other things.
# [11:35] <SimonSapin> we resolved that the value of eg. 1vw would be the same across pages, even pages of varying sizes. (ie. it’s converted to pixels at computed-value-time, unlike percentages)
# [11:35] <SimonSapin> the question is what value that is
# [11:36] <SimonSapin> not allowing viewport units in the page context removes the most obvious cycles
# [11:37] <SimonSapin> inheriting font-size from the root is indeed a use case we want to keep, but it introduces more viewport unit cycles
# [11:37] <SimonSapin> :root{font-size: 1vw} @page {width: 50em}
# [11:41] <pjrm> You did mention that there are a couple of other possible ways out of that.
# [11:41] <pjrm> That said, there isn't a clear winner.
# [11:42] <SimonSapin> it’s still an open issue, and not many people seem to want to look at it
# [11:42] <pjrm> If vw units are useful at all, then one may well want their size to vary from one page to the next, just as things like the used value of 'width' for :root can vary from one page to the next.
# [11:43] <pjrm> I mean, surely if one is using vw then one would want it to match the page where you actually use it.
# [11:44] <SimonSapin> I did say repeatedly that having 1vw be the same across pages of varying sizes makes the feature kind of useless, but browsers vendors still did not want to deal with the implementation complexity and possible performance hit
# [11:45] <pjrm> Yes, I was going to say, that's just one argument and there are counter-arguments involving complexity.
# [11:46] <pjrm> However, those same complexity arguments seem to apply just as much to the idea that the used 'width' of :root varies from one page to the next.
# [11:47] <pjrm> If you're going to re-lay-out every width for each page, then I'm not sure that re-evaluating vw is such a big additional cost.
# [11:48] <pjrm> float issues are really awkward with variable-width pages, for example.
# [11:48] <pjrm> Changing vw is trivial in comparison.
# [11:48] <SimonSapin> it’s not only layout, also the cascade: the computed value of any property that accepts <length> (some of which previously could only ever be an absolute length) suddenly can also be a viewport-percentage
# [11:49] <SimonSapin> I agree it might still be worth it, but it’s a big impact
# [11:54] <pjrm> Something vaguely related is css3-regions and the way that elements can inherit from regions in that spec. (It's been a long time since i've looked at that spec, i don't know how it works in the current version.)
# [11:55] <pjrm> Changing font-size is a relatively common use case for that.
# [11:55] <pjrm> This is somewhat similar to a changing value of vw.
# [11:56] <pjrm> That said, I'm not at all comfortable with that feature of css3-regions.
# [11:56] <pjrm> [Assuming that it is still a feature of that spec.]
# [11:58] <pjrm> Under the "don't have @page inherit from :root" option, what does 50em mean? Is it simply disallowed, as I seem to remember that it was in earlier versions of css3-page ?
# [11:59] <pjrm> (I think earlier versions of css3-page disallowed em & ex units.)
# [12:00] <pjrm> (in page context)
# [12:00] <pjrm> Ah, more likely it would have been based on UA default font-size.
# [12:01] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:01] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [12:01] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [12:03] <SimonSapin> pjrm: 50em in the page context is based on font-size in the page context
# [12:03] <SimonSapin> if there is no such declaration, it inherits
# [12:03] <pjrm> from what?
# [12:03] <SimonSapin> if there is no "parent" to inherit from, it’s the initial value
# [12:03] <pjrm> yes
# [12:04] <pjrm> as i say, the UA default font-size, which is the initial value of font-size.
# [12:04] <SimonSapin> yes
# [12:05] <pjrm> The :root{font-size: .1vw} @page {width: 50em} cycle is a short one, and there's the option of detecting it and resolving it with initial font-size.
# [12:05] <pjrm> (Actually, I think initial font-size is 'medium', it's just that the meaning of 'medium' is UA-specific.)
# [12:06] <SimonSapin> I’d rather not special-case cycles to detect. The underlying question is: what do you compute first?
# [12:07] <SimonSapin> Ideally, an implementation can determine the "viewport" before it even starts the cascade on elements
# [12:07] <pjrm> I agree that detecting it & handling it specially is extra complexity and that we might well decide against it; i'm just saying that it's one of the options on the table.
# [12:07] <pjrm> Detecting it is easier than cycle detection in general,
# [12:07] <pjrm> because it's limited to a length of 2.
# [12:09] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 60 seconds)
# [12:10] <pjrm> i agree it's icky; it's just a question of how valuable the use cases are that argue for supporting both :root font-size in vw and page content box in ems.
# [12:11] <SimonSapin> it’s not just ems, try @page { width: inherit }
# [12:11] <pjrm> For that matter, what does @page{width:2vw} do ?
# [12:11] <SimonSapin> this rule is ridiculous, but it needs to be well-defined
# [12:12] <SimonSapin> @page{width:2vw} I don’t know, that’s still to be decided
# [12:13] <SimonSapin> I’d rather not require implementation to do something like: try to do part of the cascade to get computed values of :root without knowing the size of the viewport yet, cascade @page rules inheriting from that, determine the viewport, then do the rest of the cascade on elements
# [12:13] <pjrm> I wonder, what if some things inherit from root and not others. Does that buy anything? (I suspect not much, if 'font-size' is one of the more useful ones to be inherited.)
# [12:13] <SimonSapin> I’m not sure
# [12:14] <SimonSapin> but it’s not just inheritance … if vw is based on the actual first page, we need not only the cascade but box generation, in case it’s a named page
# [12:16] <pjrm> surely the computed value of 1vw would be 1vw, not a value in px.
# [12:17] <SimonSapin> html:root>body>:first-child{display:none} html:root>body>:nth-child(2){page:wide} @page{size:A4 portrait} @page wide{size:A4 landscape}
# [12:17] <SimonSapin> the computed value of 1vw is in px with the current definition
# [12:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:18] <SimonSapin> maybe having the computed value be 1vw would help with some cycles, but browsers vendors don’t want to do that
# [12:19] <pjrm> If "browser" means "@media screen", then vw means viewport width, which is constant.
# [12:19] <pjrm> (isn't it?)
# [12:19] <SimonSapin> yes, none of this is an issue in continuous media
# [12:20] <pjrm> another off-the-top-of-my-head idea: what if vw had a constant width within a given value of 'page', does that help at all?
# [12:21] <SimonSapin> http://dev.w3.org/csswg/css-device-adapt/ explains how vw inside @viewport refers to the "initial viewport", and everywhere else to the "actual viewport" based on @viewport rules
# [12:21] <SimonSapin> not really, any page pseudo-class can also change the page size
# [12:22] <SimonSapin> I tried to write up something like @viewport for @page, but it gets crazy really fast
# [12:22] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [12:22] <pjrm> what i mean is, would it help if @page pseudo-classes couldn't change the page size.
# [12:23] <pjrm> that would at least help some of the difficulties with varying page width, even if it doesn't help with the cycle.
# [12:24] <SimonSapin> well, I’ve written huge margin-top on @page:first, which would change vh
# [12:24] <SimonSapin> but even if you have only one page size per page type, how does that help?
# [12:26] <pjrm> It helps for line-breaking, and it might help for table layout.
# [12:26] <SimonSapin> you mean to cache layout results?
# [12:27] <pjrm> it means you can do line-breaking before knowing what page each line will be on, so that there's less of a cycle between pagination and line-breaking.
# [12:27] <SimonSapin> the page size itself looks like it would work just as well as a cache key than the page "type"
# [12:29] <SimonSapin> I’m not too worried (yet) about implementation performance, viewport units in paged media are a mess even to get them well-defined
# [12:29] <SimonSapin> in the spec
# [12:33] <pjrm> What happens if different table-cell's in the same table-row have different values of 'page' ?
# [12:33] <pjrm> i seem to remember that there was some rule about page breaks not applying other than in root BFC (or something along those lines), but i forget the rule.
# [12:33] <SimonSapin> I don’t think 'page' applies to table cells
# [12:33] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [12:33] <SimonSapin> but yes, that too
# [12:34] <SimonSapin> although it seems to have been lost in the last ED
# [12:34] <pjrm> change the example to div's inside different cells of the same row, if you prefer.
# [12:35] <SimonSapin> I don’t know
# [12:36] <SimonSapin> feedback on any of all this is very welcome :)
# [12:36] <pjrm> if it doesn't apply to table-row or descendants, then restricting page content box width to be constant within a given named page would help table layout because one would always know what page width applied to a given table row,
# [12:37] <pjrm> rather than having the question of what page it's on depend on how tall previous rows are, which depends on what page and page width they're on.
# [12:37] <SimonSapin> you can have a "class 1" break between two rows, so I think 'page' applies on rows
# [12:38] <pjrm> sorry, i meant to say "table-cell or descendants".
# [12:38] <pjrm> That's what i thought in my head, i don't know why i typed table-row or descendants.
# [12:38] <SimonSapin> ah I see
# [12:38] <SimonSapin> yes that would help table layout
# [12:39] <SimonSapin> (weasyprint doesn’t yet support page breaks inside table cells anyway …)
# [12:43] <pjrm> Morp doesn't support varying page content box at all, but it would be easier to support varying it between different named page styles than allowing e.g. @page :nth(247) { width: different-from-the-rest }. Differing widths between :left & :right is between the two in difficulty.
# [12:43] <pjrm> The problem with varying width is that it interferes with optimal line breaking.
# [12:44] <SimonSapin> We don’t have :nth() page selectors, but I get your point
# [12:44] <pjrm> css3-gcpm has it
# [12:44] <SimonSapin> oh
# [12:45] <SimonSapin> hum, I see ::page() on elements
# [12:45] <SimonSapin> but I don’t know if either is a good idea
# [12:46] <pjrm> Speaking of css3-gcpm, there seems to be some confusion about what @page chapter:first means: I've seen some text somewhere that assumes that it means the first page of each chapter, whereas i think per current css3-page it matches only the first page of the document if that first page has 'page' value 'chapter'.
# [12:47] <pjrm> Have you come across both these notions?
# [12:47] <pjrm> (and am i remembering correctly as to its meaning in current css3-page ?)
# [12:48] <pjrm> (where "of each chapter" of course assumes that each chapter element sets 'page' to 'chapter' rather than 'auto'.)
# [12:49] <SimonSapin> css3-page is clear that :first is the first of the document, even in older drafts
# [12:50] <SimonSapin> nothing in css3-page indicates that changes when :first is combined with a page type selector
# [12:50] <SimonSapin> where do you see the other interpretation in GCPM?
# [12:51] <pjrm> ah, i see that this functionality has now been renamed to :first-page, and the definition has changed a bit too.
# [12:51] <SimonSapin> ::first-page is a pseudo-element in style rules, not @page rules
# [12:52] <pjrm> that's what i meant about definition changing a bit, applying now to elements.
# [12:52] <SimonSapin> it needs to restrict what properties apply, for the same reasons as in ::first-letter and ::first-line
# [12:54] <pjrm> [My own inclination is to restrict that set to {}, at least until ::first-line and ::first-letter actually get defined in a spec.]
# [12:55] <pjrm> They were one of a few things that we didn't get to define for CSS 2.1.
# [12:56] <pjrm> (Hmm, "they were one". I must work on my English language skills.)
# [12:57] <SimonSapin> hum, looks pretty much defined to me: http://www.w3.org/TR/CSS21/selector.html#pseudo-element-selectors
# [12:58] <SimonSapin> with a list of properties that apply
# [12:58] <SimonSapin> level 3 modules sometimes say: these properties apply/does not apply on ::first-letter/::first-line
# [13:04] <SimonSapin> unfortunately many parts of GCPM are under-specified, if not just crazy
# [13:04] <SimonSapin> it’s more of a wish-list than a spec
# [13:04] <pjrm> there are a number of issues raised concerning :first-line and (i think perhaps to a lesser extent) :first-letter before CSS 2.1 went to PR. Due to the hurry for CSS2.1, the response to those issues was just to add a note saying that some aspects aren't fully defined by CSS 2.1.
# [13:05] <pjrm> re :first, i might have been thinking of chapter:nth(1).
# [13:06] <SimonSapin> "the sections below do not define the exact rendering of ':first-line' and ':first-letter' in all cases." I’m not sure what that means
# [13:06] <pjrm> me neither :) . As i say, it was added in a bit of a rush.
# [13:07] <pjrm> one of the problems wasn't of undefined behaviour but of contradictorily defined behaviour.
# [13:08] <SimonSapin> I haven’t implemented these either
# [13:10] <pjrm> A google search for "@page chapter:first" produces a few hits.
# [13:12] <pjrm> However, I do get the impression that the idea of "@page chapter:first" (in the sense of first page of each chapter) has now been dropped.
# [13:13] <pjrm> FWIW, my approach to "have different page header on first page of the chapter" was by using named strings.
# [13:15] <pjrm> I achieved different styling for that heading by using a different page-margin box. Both page-margin boxes were displayed all the time, but only one had non-empty content on a given page.
# [13:17] <pjrm> Re gcpm, some of the craziness that glazou objected is relatively recent. The spec didn't strike me as crazy a few years ago.
# [13:20] <pjrm> I think the footnote separator line should be implemented with an image rather than introduce a partial border, but most of that magic does actually seem to be required to get that functionality. Sure, if you were writing it today then you might use flows, but most of the magic would remain.
# [13:21] <pjrm> (magic for footnotes, i mean.)
# [13:21] <SimonSapin> yeah, footnotes are hard
# [13:22] <pjrm> I'm not at all sure that flows are appropriate for doing the PDF outline as glazou suggests.
# [13:23] <pjrm> PDF outline is limited to plain text.
# [13:23] <SimonSapin> yes, bookmarks is one of the better parts of gcpm imo
# [13:24] <SimonSapin> although maybe it’s redundant with the HTML outline algorithm
# [13:25] <pjrm> part of the disagreement seems to come down to intended uses: the current bookmark solution is focused on PDF document outline, whereas glazou is approaching the question from a web browser perspective.
# [13:26] <pjrm> a weakness of using the HTML outline algorithm is that things like floats or "Note/Warning" boxes can have headings, but those headings shouldn't show up in the document outline.
# [13:26] <pjrm> Similarly, you probably don't want a PDF document outline entry for the Table of Contents heading.
# [13:27] <SimonSapin> I see
# [13:27] <SimonSapin> so we need something in CSS to disable some parts of the outline
# [13:27] <SimonSapin> still, I hope they can be unified
# [13:28] <SimonSapin> although traditionally CSS tries not to have anything HTML specific
# [13:29] <pjrm> what does html5 say about the case of "<body><h5>A heading</h5></body>" ? The pdf document outline really wants each outline entry to have a parent.
# [13:29] <SimonSapin> I don’t know
# [13:29] <SimonSapin> that’s undefined with gcpm bookmarks
# [13:30] <pjrm> the main goal was just that css would work well with html. E.g. the css3-gcpm approach was designed to work well with html4, and just happens not to work as elegantly for html5 or some other document arrangements.
# [13:31] * Joins: teoli (~teoli@public.cloak)
# [13:50] <pjrm> 'night.
# [13:50] * Quits: pjrm (~pjrm@public.cloak) ("Leaving.")
# [14:30] * Joins: jarek (~jarek@public.cloak)
# [15:28] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [15:35] * Quits: jarek (~jarek@public.cloak) (jarek)
# [16:13] * Joins: rhauck (~Adium@public.cloak)
# [16:15] * Joins: rhauck1 (~Adium@public.cloak)
# [16:17] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [16:24] * Joins: lmclister (~lmclister@public.cloak)
# [16:40] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [16:40] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [17:00] * Joins: cabanier (~cabanier@public.cloak)
# [17:15] * Joins: rhauck (~Adium@public.cloak)
# [17:37] * Joins: krit (~krit@public.cloak)
# [17:39] * Quits: arronei (~arronei@public.cloak) ("")
# [17:41] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [17:44] * Joins: arronei (~arronei@public.cloak)
# [17:49] * Joins: jarek (~jarek@public.cloak)
# [17:49] * Joins: krit (~krit@public.cloak)
# [18:05] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:08] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:08] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [18:18] * Joins: cabanier (~cabanier@public.cloak)
# [18:34] * Quits: arronei (~arronei@public.cloak) ("")
# [18:36] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:36] * Joins: arronei (~arronei@public.cloak)
# [18:36] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:36] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:44] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 60 seconds)
# [18:56] * Joins: rhauck1 (~Adium@public.cloak)
# [18:57] * Joins: rhauck2 (~Adium@public.cloak)
# [18:57] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [18:58] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [19:28] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [19:38] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 60 seconds)
# [19:39] * Joins: lmclister (~lmclister@public.cloak)
# [19:40] * Quits: rhauck2 (~Adium@public.cloak) ("Leaving.")
# [19:41] * Joins: rhauck (~Adium@public.cloak)
# [19:42] * Joins: rhauck1 (~Adium@public.cloak)
# [19:42] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [19:49] * Joins: isherman-book (~Adium@public.cloak)
# [19:50] * Quits: jarek (~jarek@public.cloak) (jarek)
# [19:54] * Joins: jet (~junglecode@public.cloak)
# [20:06] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [20:19] * leaverou is now known as leaverou_away
# [20:21] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [20:22] * leaverou_away is now known as leaverou
# [20:25] * Joins: abucur (~abucur@public.cloak)
# [20:35] * Joins: isherman-book (~Adium@public.cloak)
# [20:41] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [20:43] * Joins: darktears (~darktears@public.cloak)
# [20:53] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [20:53] * Joins: krit (~krit@public.cloak)
# [20:56] * Joins: {Darktears} (~darktears@public.cloak)
# [20:58] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [21:00] * {Darktears} is now known as darktears
# [21:01] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [21:05] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 60 seconds)
# [21:07] * Joins: lmclister (~lmclister@public.cloak)
# [21:11] * Joins: isherman-book (~Adium@public.cloak)
# [21:13] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:20] * Quits: isherman-book (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [21:26] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [21:32] * Joins: darktears (~darktears@public.cloak)
# [21:41] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [21:44] * Joins: isherman-book (~Adium@public.cloak)
# [21:44] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 60 seconds)
# [21:49] * Quits: jet (~junglecode@public.cloak) (Ping timeout: 60 seconds)
# [21:56] * Joins: jet (~junglecode@public.cloak)
# [22:22] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [22:36] * Joins: jarek (~jarek@public.cloak)
# [22:51] * Joins: SimonSapin (~simon@public.cloak)
# [23:05] * Quits: jet (~junglecode@public.cloak) (jet)
# [23:18] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [23:28] * Joins: isherman-book (~Adium@public.cloak)
# [23:30] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [23:43] * Joins: shanestephens (~shanestephens@public.cloak)
# [23:48] * Joins: zcorpan (~zcorpan@public.cloak)
# [23:51] * Quits: abucur (~abucur@public.cloak) ("Leaving")
# [23:56] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 60 seconds)
# [23:59] * Quits: jarek (~jarek@public.cloak) (jarek)
# Session Close: Wed Mar 20 00:00:00 2013

The end :)