the lines remain intact and just stretch across the page, rather than remaining inside the original bounds of the text box and flowing to the next line.
You can see what happens when Xtreme does flow to the next line by using justified text. This changes the text layout to a block-based one with reflow.

The problem is in this case the differences in text size pile up, instead of resetting on each line. Then the end of a block of text can crash into the next block or the bottom of the page. This is typically a worse failure than each line growing independently.

Text size on the web is never reliable. There can be small differences due to font replacements and different rendering options and rounding, or more significant differences due to the user changing the text size. (There are many options that can affect text size across many browsers, not just the default text resizer on the View menu.) With Xtreme the best way to cope with this is to include lots of whitespace and wide leading, so that there is a buffer for text to grow a bit larger without breaking everything.

The 'proper' web way to do it is to allow the page to grow bigger and smaller in response to font size changes and window resizing. But that's simply not possible in a visual-based (WYSIWYG) design tool like Xtreme. There would have to be huge changes to Xtreme's capabilities to make it understand pages in which certain areas can grow and shrink - effectively it would have to become a full-on web authoring package. And I don't think that's a fruitful direction to take a vector graphics editor.