This patch makes it possible to call Node::invalidate_style() and have
that node and all of its ancestors recompute their style.
We then figure out if the new style is visually different from the old
style, and if so do a paint invalidation with set_needs_display().
Note that the "are they visually different" code is very incomplete!
Use this to make hover effects a lot more efficient. They no longer
cause a full relayout+repaint, but only a style invalidation.
Style invalidations are still quite heavy though, and there's a lot of
room for improvement there. :^)
These helpers return the next/previous sibling Node that's actually an
element. This will be useful in the CSS engine since CSS doesn't care
about text nodes.
Instead of branching on the Node type, let subclasses decide how their
layout nodes get constructed.
This will allow elements to create custom layout nodes if they want.
This patch implements basic support for presentational hints, which are
old-school HTML attributes that affect style.
You add support for a presentational hint attribute by overriding
Element::apply_presentational_hints(StyleProperties&) and setting all
of the corresponding CSS properties as appropriate.
To make the background color fill the entire document, not just the
bounds of the <body> element's LayoutNode, we special-case it in the
HtmlView::paint_event() code for now. I'm not entirely sure what the
nicest solution would be, but I'm sure we'll discover it eventually.
This patch makes StyleProperties heap-allocated and ref-counted so that
a LayoutNode can be without one. The ref-counting also allows anonymous
blocks to share style with their parent block.
LayoutText never needs a StyleProperties, since text always inherits
style from its parent element. This is handled by style_properties().
We now show a tooltip for the hovered node's enclosing HTML element's
title attribute, if one is present.
This patch also adds HTMLHeadingElement. The tags h1-h6 will now create
the right kind of objects.
This also fixes another bug with inline wrappers. Namely,
we should only add inline wrappers if a block node has
both non-block (inline or text) and block children.
