| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
That's where it's supposed to be declared.
|
|
|
|
|
|
Move the image file detection code to the File class to prevent code duplication.
|
|
This fixes https://github.com/SerenityOS/serenity/issues/2498
A nullptr dereference was caused by the visual data beeing out of sync
with the line data, due to a deferred recompute.
|
|
This was useful in debugging a nullptr dereference, which was happening
through later, but was caused by this inconsistent initialization.
|
|
|
|
We're not supposed to load these by default. Alternate stylesheets can
be offered in a menu or something, if the user is interested.
|
|
|
|
We're never gonna be able to run them if we can't load them so just
let it go.
|
|
|
|
Not doing this was causing the wrong kind of LayoutNode to stay around
even though we had the final "display" value.
|
|
Hey, why not. We did all the hard work for display:inline-block already
and now we can just allow this.
This makes <a><h1>Hello friends!</h1></a> work :^)
|
|
To support z-ordering when painting, the layout tree now has a parallel
sparse tree of stacking contexts. The rules for which layout boxes
establish a stacking context are a bit complex, but the intent is to
encapsulate the decision making into establishes_stacking_context().
When we paint, we start from the ICB (LayoutDocument) who always has a
StackingContext and then paint the tree of StackingContexts where each
node has its children sorted by z-index.
This is pretty crude, but gets the basic job done. Note that this does
not yet support hit testing; hit testing is still done using a naive
treewalk from the root.
|
|
The only layout nodes that don't have their own style are LayoutText
(they inherit the style from their parent element since text cannot
be styled by CSS.)
However, it never makes sense for text nodes to have absolute position
so don't claim it.
|
|
Implemented in user space for now.
|
|
|
|
We can just log that we don't know what to do for now.
|
|
|
|
This should technically apply to any LayoutImage, so let's just move
it to ImageLoader.
|
|
Since ImageLoader manages the image decoder anyway, let it manage
animation as well.
|
|
|
|
|
|
Previously, layout recursively performed these steps (roughly):
1. Compute own width
2. Compute own position
3. Layout in-flow children
4. Compute own height
5. Layout absolutely positioned descendants
However, step (2) was pretty inconsistent. Some things computed their
own position, others had their parent do it for them, etc.
To get closer to CSS spec language, and make things easier in general,
this patch reorganizes the algorithm into:
1. Compute own width & height
2. Compute width & height of in-flow managed descendants
3. Move in-flow managed descendants to their final position
4. Layout absolutely positioned descendants
Block layout is now driven by the containing block, which will iterate
the descendants it's responsible for. There are a lot of inefficient
patterns in this logic right now, but they can easily be replaced with
better iteration functions once we settle on a long-term architecture.
Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a
containing block to move it into place.
This code is still evolving along with my understanding of CSS layout,
so it's likely that we'll reorganize this again sooner or later. :^)
|
|
|
|
No need to worry about inline children if children are not inline(!)
|
|
Any live layout tree always has a corresponding live Frame, as we will
never create a layout tree for a frameless document.
|
|
Just paint it like an empty box if there's no document in the frame.
|
|
Also fixes some little mistakes in the "in body" insertion mode
that I found whilst cross-referencing.
|
|
|
|
|
|
Even though we haven't implemented any switches to these states yet,
we may as well have them ready for when we do implement the switches.
|
|
Also fixes TagOpen having a seperate emit and reconsume in
ANYTHING_ELSE.
|
|
|
|
This patch implements a simple <object> element with fallback content.
If the URL from the data attribute fails to load (including 404),
we render the DOM tree inside the <object> as fallback content.
This works by generating a different layout tree for the <object>
depending on the state and success of the data load. Since we cannot
currently do incremental layout tree updates, we have to force a
complete layout tree rebuild when the resource load finishes/fails.
|
|
Since more DOM nodes are going to want to load images (<object>, ...)
this patch splits out the image loading logic into an ImageLoader class
and then HTMLImageElement simply has an ImageLoader.
LayoutImage is then given a const ImageLoader& at construction and can
then provide layout and rendering for many kinds of DOM nodes.
|
|
|
|
Clients now receive HTTP status codes like 200, 404, etc.
Note that a 404 with content is still considered a "successful"
download from ProtocolServer's perspective. It's up to the client
to interpret the status code.
I'm not sure if this is the best API, but it'll work for now.
|
|
The good boy fix here would be to implement all of the CSS paint phases
but for now, let's at least not paint a background over our image. :^)
|
|
|
|
Otherwise we won't get the first fully styled look until you interact
with the page (e.g via hovering an element.)
|
|
|
|
|
|
...so when we check for rel=stylesheet, we have to split it up into
parts first. :^)
|
|
|
|
|
|
This adds support for decoding the Adam7 interlacing used in some PNGs.
Notably this includes many of the images (such as the eyes) used in the acid2 test :^)
Note that the HTML engine still doesn't understand the <object> tag well enough to show the eyes on the test.
|
|
|
