Note our Attribute class is what the spec refers to as just "Attr". The
main differences between the existing implementation and the spec are
just that the spec defines more fields.
Attributes can contain namespace URIs and prefixes. However, note that
these are not parsed in HTML documents unless the document content-type
is XML. So for now, these are initialized to null. Web pages are able to
set the namespace via JavaScript (setAttributeNS), so these fields may
be filled in when the corresponding APIs are implemented.
The main change to be aware of is that an attribute is a node. This has
implications on how attributes are stored in the Element class. Nodes
are non-copyable and non-movable because these constructors are deleted
by the EventTarget base class. This means attributes cannot be stored in
a Vector or HashMap as these containers assume copyability / movability.
So for now, the Vector holding attributes is changed to hold RefPtrs to
attributes instead. This might change when attribute storage is
implemented according to the spec (by way of NamedNodeMap).
ProcFSGlobalInode now calls `write_bytes()`, `truncate()` and
`set_mtime()` on its associated component. This allows us to write 0 or
1 to a ProcFSSystemBoolean component to toggle a boolean value.
We are doing nonstandard stuff with our headers, so SDL assumed that
both iconv and dlopen are available inside LibC, which they aren't.
Fix that by adding a dependency on libiconv and adding additional
linker flags.
I originally implemented this as something to use the new sequence
wrapper, however, after having a look at uses with grep.app, it's used
often, for example:
- Bootstrap 5 Dropdowns
- Polymer
- Angular
- Closure
This adds the ParamatizedType, as `Vector<String>` doesn't encode the
full type information. It is a separate struct as you can't have
`Vector<Type>` inside of `Type`. This also makes Type RefCounted
because I had to make parse_type return a pointer to make dynamic
casting work correctly.
The reason I made it RefCounted instead of using a NonnullOwnPtr is
because it causes compiler errors that I don't want to figure out right
now.
Previously, when the last layer got deleted, the active layer was
set to nullptr, causing a crash.
Now, we create a new transparent background layer with the image
dimensions instead.
We want to check the last SimpleSelector, not the first one. We don't
have to check that a SimpleSelector exists since a CompoundSelector
without one is invalid.
Also, renamed `builder` to `s` to match spec comments, and fixed a
find-and-replace typo where some pseudo-class names were
"last-of-pseudo_class" instead of "last-of-type".
This implements these algorithms from the CSSOM-1 spec:
- serialize a string
- serialize a URL
Also, we now have two versions of each of the serialization functions:
One that returns a String as before, and the other that takes a
StringBuilder to write into. This saves creating extra StringBuilders
when they are not needed. :^)
Apparently it breaks the fuzzer build. There's probably a better fix
for this, but for now just unbreak the fuzzer build.
Keep this for non-fuzzer builds though since it's apparently a 17%
speedup for running test262 tests :^)
All its members are comparable themselves, so this can be defaulted.
Making it comparable will allow us, among other things, to check if a
list of symbols (i.e., the result of calling the symbolicate functions)
is equal or not to another, which in turn will allow us to avoid
refreshing the SystemMonitor's Stack tab when successive symbolicated
stacks are the same.
This function converts a single wide character into its multibyte
representation (UTF-8 in our case). It is called from libc++'s
`std::basic_ostream<wchar_t>::flush`, which gets called at program exit
from a global destructor in order to flush `std::wcout`.
Lagom: Build with -fno-no-semantic-interposition
We build with this in non-lagom builds, and serenity's gcc even adds it
to its CC1_SPEC. Let's use it for lagom too.
Reduces the number of dynamic relocations in liblagom-js.so.0.0.0 (per
`objdump -R`) from 15133 to 14534, and increases its size back to 91M
(95156800 bytes), probably due to more inlining being possible.
This might help perf of lagom binaries.
We build with this in non-lagom builds, so there's no reason not
to use it in lagom builds as well.
Reduces the size of liblagom-js.so.0.0.0 from 94M to 90M
(from 98352784 to 93831056 bytes to be exact).
