Table row containing floats do not float and makes row height incorrect #388

Closed
jeffgabhart opened this Issue Nov 16, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@jeffgabhart

Here is a simplified example of the html I'm using. The floats inside the table are not respected and there is a lot of extra space between the rows. Maybe 2x the height of the divs when they are stacked.

<table>
  <colgroup>
    <col>
  </colgroup>
  <tbody>
    <tr>
      <td>
        <div style="float: left;">Value 1</div>
        <div style="float: left;">Value 2</div>
        <div style="float: left;">Value 3</div>
      </td>
    </tr>
    <tr>
      <td>
        <div style="float: left;">Value 1</div>
        <div style="float: left;">Value 2</div>
        <div style="float: left;">Value 3</div>
      </td>
    </tr>
    <tr>
      <td>
        <div style="float: left;">Value 1</div>
        <div style="float: left;">Value 2</div>
        <div style="float: left;">Value 3</div>
      </td>
    </tr>
   </tbody>
</table>

Chrome output:
image
Weasyprint output:
image

I can get these onto the same line using the following, but again the space between looks like the height of the divs if they were stacked.

<table>
  <colgroup>
    <col>
  </colgroup>
  <tbody>
    <tr>
      <td>
        <div style="float: left; position: relative; top: 0px; left: 8px; width: 120px; margin-right:-120px;">Value 1</div>
        <div style="float: left; position: relative; top: 0px; left: 142px; width: 120px; margin-right:-120px;">Value 2</div>
        <div style="float: left; position: relative; top: 0px; left: 277px; width: 184px; margin-right:-184px;">Value 3</div>
      </td>
    </tr>
    <tr>
      <td>
        <div style="float: left; position: relative; top: 0px; left: 8px; width: 120px; margin-right:-120px;">Value 1</div>
        <div style="float: left; position: relative; top: 0px; left: 142px; width: 120px; margin-right:-120px;">Value 2</div>
        <div style="float: left; position: relative; top: 0px; left: 277px; width: 184px; margin-right:-184px;">Value 3</div>
      </td>
    </tr>
    <tr>
      <td>
        <div style="float: left; position: relative; top: 0px; left: 8px; width: 120px; margin-right:-120px;">Value 1</div>
        <div style="float: left; position: relative; top: 0px; left: 142px; width: 120px; margin-right:-120px;">Value 2</div>
        <div style="float: left; position: relative; top: 0px; left: 277px; width: 184px; margin-right:-184px;">Value 3</div>
      </td>
    </tr>
   </tbody>
</table>

Chrome output:
image

Weasyprint output:
image

@liZe liZe added the bug label Nov 17, 2016

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Nov 17, 2016

Member

There are two different issues:

  • the floating boxes are not side by side because the preferred size of the cell doesn't include floats (I'm not sure that's it's defined in the spec, but it would definitely be an improvement in WeasyPrint),
  • the height is strange, really strange, I really don't know what's going on 😄.
Member

liZe commented Nov 17, 2016

There are two different issues:

  • the floating boxes are not side by side because the preferred size of the cell doesn't include floats (I'm not sure that's it's defined in the spec, but it would definitely be an improvement in WeasyPrint),
  • the height is strange, really strange, I really don't know what's going on 😄.
@jeffgabhart

This comment has been minimized.

Show comment
Hide comment
@jeffgabhart

jeffgabhart Nov 17, 2016

So obviously, the height thing can be recreated with my simplified examples, but my production html seems ok now, and I'm not sure what I changed to fix it..

So obviously, the height thing can be recreated with my simplified examples, but my production html seems ok now, and I'm not sure what I changed to fix it..

liZe added a commit that referenced this issue Nov 24, 2016

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe Nov 24, 2016

Member

92b3dbd fixes the second part of the bug.

The first one is not really a bug, as it's definitely not defined in the specs:

  • CSS 2.1 tells that the remainder of this section is non-normative,
  • even David Baron's More precise definitions of intrinsic widths and table layout says "The handling of floats within the definition of max-content width of blocks is not yet written properly" and "Note that the current behavior of Web browsers for handling intrinsic widths of blocks containing floats is not very interoperable."

It's really easy to make other browsers give "wrong" results for preferred size:

<table>
  <tbody>
    <tr style="background: red">
      <td>
        <div><div style="float: left;">float 1</div></div>
        <div><div style="float: left;">float 2</div> normal long text</div>
      </td>
    </tr>
   </tbody>
</table>

The result with Chrome for example:
chrome

There's an extra padding at the right of the cell.

WeasyPrint's rendering is "better" here:
wp

Short answer: I think that there's no need to solve a "problem" that's not specified, not solved by other browsers and not solved by David Baron (probably the very best specialist about tables and preferred-widths of the whole universe).

Member

liZe commented Nov 24, 2016

92b3dbd fixes the second part of the bug.

The first one is not really a bug, as it's definitely not defined in the specs:

  • CSS 2.1 tells that the remainder of this section is non-normative,
  • even David Baron's More precise definitions of intrinsic widths and table layout says "The handling of floats within the definition of max-content width of blocks is not yet written properly" and "Note that the current behavior of Web browsers for handling intrinsic widths of blocks containing floats is not very interoperable."

It's really easy to make other browsers give "wrong" results for preferred size:

<table>
  <tbody>
    <tr style="background: red">
      <td>
        <div><div style="float: left;">float 1</div></div>
        <div><div style="float: left;">float 2</div> normal long text</div>
      </td>
    </tr>
   </tbody>
</table>

The result with Chrome for example:
chrome

There's an extra padding at the right of the cell.

WeasyPrint's rendering is "better" here:
wp

Short answer: I think that there's no need to solve a "problem" that's not specified, not solved by other browsers and not solved by David Baron (probably the very best specialist about tables and preferred-widths of the whole universe).

@liZe liZe closed this Nov 24, 2016

@liZe liZe added this to the v0.33 milestone Nov 24, 2016

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Jan 15, 2017

kleink
Update py-weasyprint to 0.34.
Version 0.34
------------

Released on 2016-12-21.

Bug fixes:

* `#398 <Kozea/WeasyPrint#398>`_:
  Honor the presentational_hints option for PDFs.
* `#399 <Kozea/WeasyPrint#399>`_:
  Avoid CairoSVG-2.0.0rc* on Python 2.
* `#396 <Kozea/WeasyPrint#396>`_:
  Correctly close files open by mkstemp.
* `#403 <Kozea/WeasyPrint#403>`_:
  Cast the number of columns into int.
* Fix multi-page multi-columns and add related tests.


Version 0.33
------------

Released on 2016-11-28.

New features:

* `#393 <Kozea/WeasyPrint#393:
  Add tests on MacOS.
* `#370 <Kozea/WeasyPrint#370>`_:
  Enable @font-face on MacOS.

Bug fixes:

* `#389 <Kozea/WeasyPrint#389>`_:
  Always update resume_at when splitting lines.
* `#394 <Kozea/WeasyPrint#394>`_:
  Don't build universal wheels.
* `#388 <Kozea/WeasyPrint#388>`_:
  Fix logic when finishing block formatting context.


Version 0.32
------------

Released on 2016-11-17.

New features:

* `#28 <Kozea/WeasyPrint#28>`_:
  Support @font-face on Linux.
* Support CSS fonts level 3 almost entirely, including OpenType features.
* `#253 <Kozea/WeasyPrint#253>`_:
  Support presentational hints (optional).
* Support break-after, break-before and break-inside for pages and columns.
* `#384 <Kozea/WeasyPrint#384:
  Major performance boost.

Bux fixes:

* `#368 <Kozea/WeasyPrint#368>`_:
  Respect white-space for shrink-to-fit.
* `#382 <Kozea/WeasyPrint#382>`_:
  Fix the preferred width for column groups.
* Handle relative boxes in column-layout boxes.

Documentation:

* Add more and more documentation about Windows installation.
* `#355 <Kozea/WeasyPrint#355:
  Add fonts requirements for tests.


Version 0.31
------------

Released on 2016-08-28.

New features:

* `#124 <Kozea/WeasyPrint#124>`_:
  Add MIME sniffing for images.
* `#60 <Kozea/WeasyPrint#60>`_:
  CSS Multi-column Layout.
* `#197 <Kozea/WeasyPrint#197>`_:
  Add hyphens at line breaks activated by a soft hyphen.

Bux fixes:

* `#132 <Kozea/WeasyPrint#132>`_:
  Fix Python 3 compatibility on Windows.

Documentation:

* `#329 <Kozea/WeasyPrint#329>`_:
  Add documentation about installation on Windows.


Version 0.30
------------

Released on 2016-07-18.

WeasyPrint now depends on html5lib-0.999999999.

Bux fixes:

* Fix Acid2
* `#325 <Kozea/WeasyPrint#325>`_:
  Cutting lines is broken in page margin boxes.
* `#334 <Kozea/WeasyPrint#334>`_:
  Newest html5lib 0.999999999 breaks rendering.


Version 0.29
------------

Released on 2016-06-17.

Bug fixes:

* `#263 <Kozea/WeasyPrint#263:
  Don't crash with floats with percents in positions.
* `#323 <Kozea/WeasyPrint#323>`_:
  Fix CairoSVG 2.0 pre-release dependency in Python 2.x.


Version 0.28
------------

Released on 2016-05-16.

Bug fixes:

* `#189 <Kozea/WeasyPrint#189>`_:
  ``white-space: nowrap`` still wraps on hyphens
* `#305 <Kozea/WeasyPrint#305>`_:
  Fix crashes on some tables
* Don't crash when transform matrix isn't invertible
* Don't crash when rendering ratio-only SVG images
* Fix margins and borders on some tables


Version 0.27
------------

Released on 2016-04-08.

New features:

* `#295 <Kozea/WeasyPrint#295>`_:
  Support the 'rem' unit.
* `#299 <Kozea/WeasyPrint#299>`_:
  Enhance the support of SVG images.

Bug fixes:

* `#307 <Kozea/WeasyPrint#307>`_:
  Fix the layout of cells larger than their tables.

Documentation:

* The website is now on GitHub Pages, the documentation is on Read the Docs.
* `#297 <Kozea/WeasyPrint#297>`_:
  Rewrite the CSS chapter of the documentation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment