Many properties can now have percentage values that get resolved in
layout. The reference value (what is this a percentage *of*?) differs
per property, so I've added a helper where you provide a reference
value as an added parameter to the existing length_or_fallback().
Currently we don't deal with them, so they shouldn't return a
SimpleSelector - that'd be a false positive.
Also don't produce a ComplexSelector if no SimpleSelector was parsed.
This fixes a couple of rendering issues on awesomekling.github.io:
link colours, footer size, content max-width (and possibly more!)
Previously we would only check if the border width property is empty and
skip drawing in that case, and enforcing a minimum width of 1px
otherwise - but "border: 0;" should not paint a border :^)
We now look at the Content-Type HTTP header when deciding how to render
some loaded content. If there is no Content-Type header (which will
always be the case when loading local files, for example), we make a
guess based on the URL filename.
This is a workaround for the silly issue where some content would move
one pixel upward on every layout. The block layout code was finding
the list item marker and doing regular inline layout on it. We were not
prepared to handle this, which caused it to move in a silly way.
For now, just regenerate markers on every layout to work around the
issue. In the future we should figure out a nice way to layout markers.
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
This implements only one of the two forms of this function,
ctx.fill(winding_rule).
Also tweaks the quadratic curve demo to have a nice looking filled
shape.
This display type is implemented using a LayoutBlock that is_inline().
Basically it behaves like a block internally, and its children are laid
out in the normal block layout fashion. Externally however, it behaves
like an atomic inline-level box.
Layout of inline-block boxes happens in three stages:
1. The outer dimensions of the block are computed during the recursive
normal layout pass. We skip positioning, but lay out children.
2. Later on, during line layout in the *containing block*, the inline
block now contributes a linebox fragment. When linebox fragments are
positioned, we learn the final position of the inline block. That's
when we set the inline block's position.
3. We re-layout the inline block's children once again. This is done to
make sure they end up in the right position. The layout tree doesn't
use relative offsets, so after we position the inline block in (2),
its children will not have its positions updated. Relayout moves
all children of inline blocks to the right place.
This is a rather naive approach but it does get the basic behavior into
place so we can iterate on it. :^)
It's still only a dummy as LibWeb doesn't have focused elements yet, but
at least now we don't treat "selector:focus" as just "selector".
This fixes an issue on google.com which was mostly grey - coming from
some menu item focus styles :^)
The spec defines the only valid methods to be get, post, and dialog.
Post and dialog are currently unhandled and do nothing, any other value
(or no value specified) is defined by the spec to use the get method.
Previously we would use the "content rect" as the viewport rect, which
could sometimes be smaller than the actual viewport rect as the content
size was based on the box geometry of the root layout node.
This fixes an issue on google.com where we would not render the main
logo image since it was "outside" the viewport. The root layout size
is currently very wrong on google.com but that's a separate issue. :^)
We're starting with a very basic decoding API and only ISO-8859-1 and
UTF-8 decoding (and UTF-8 decoding is really a no-op since String is
expected to be UTF-8.)
We now look at the HTTP response headers for a Content-Type header and
try to parse it if present to find the text encoding.
If the text encoding is iso-8859-1, we turn all non-ASCII characters
into question marks. This makes Swedish Google load on my machine! :^)
We now store the response headers in a download object on the protocol
server side and pass it to the client when finishing up a download.
Response headers are passed as an IPC::Dictionary. :^)
Added the ability to include a u8 attributes parameter with all of the
various put methods in the Object class. They can be omitted, in which
case it defaults to "Writable | Enumerable | Configurable", just like
before this commit.
All of the attribute values for each property were gathered from
SpiderMonkey in the Firefox console. Some properties (e.g. all of the
canvas element properties) have undefined property descriptors... not
quite sure what that means. Those were left as the default specified
above.
