If an element is created from JS, it might have its contents modified
before it is inserted into the document. In this case, we don't have a
shadow tree yet and so trying to set m_text_node's text content would
cause a null dereference. So let's not do that. :^)
That case also means that by the time we do create the shadow tree, we
have the text content already, so we can set it there.
Added a test to verify that we don't crash, and that the text content
appears in the textarea whether it was inserted by JS or by the HTML
parser.
Give it a shadow tree, similar to HTMLInputElement's, so that we can
actually edit its contents at a basic level. Add some CSS to use the
`rows` and `cols` attributes as the size if they are present.
HTMLTextAreaElement also needs to be told when its contained text node
has been edited, so let's make this functionality work for anyone who
extends the new EditableTextNodeOwner interface class.
This should allow us to add a Element::attribute which returns an
Optional<String>. Eventually all callers should be ported to switch from
the DeprecatedString version, but in the meantime, this should allow us
to port some more IDL interfaces away from DeprecatedString.
This allows us to retain perfect precision for aspect ratios derived
from either the intrinsic sizes of replaced elements, or the
`aspect-ratio` CSS property.
Which for now will just call the DeprecatedString version of this
function. This is intended to be used in porting code over to using the
new String equivalent with the end goal of removing the DeprecatedString
version of this function.
This allows us to port a whole heap of IDL interfaces from
DeprecatedString to String.
NewAKString is effectively the default for any new IDL interface, so
let's mark this as the default behavior. It also makes it much easier to
figure out whatever interfaces are still left to port over to new AK
String.
This is a bit iffy, but since <br> elements can't be implemented in
"just CSS" today, we should also exclude them from the blockification
algorithm. This is important, since <br> is expected to always have
inline-like behavior.
There is only one, width/height -> aspect-ratio. This brings us
very slightly closer to spec and triggers a re-layout after
updating these values from JavaScript, which wasn't the case
before.
We currently track the [line, column] position of every HTMLToken, as
this is what is needed for LibGUI's syntax highlighting. Some non-LibGUI
purposes (e.g. highlighting HTML with HTML) require a byte offset. Track
both during tokenization.
This moves some stuff around to make LibGUI depend on LibSyntax instead
of the other way around, as not every application that wishes to do
syntax highlighting is necessarily a LibGUI (or even a GUI) application.
While we're here, assert that we're not doing this conversion when the
NavigationHistoryBehavior is still "auto", as the
HistoryHandlingBehavior enum is supposed to represent a "resolved"
behavior.
Instead of having a nested enum within a struct, use the macro
AK_ENUM_BITWISE_OPERATORS to add all the convienent has_flag free
functions and such for ease of use.
The FIXME here describes an old constraint on JS Interpreters which no
longer holds. It hails from a time when we had the global object and
JS realm attached to the document.
The proper abstract operations on Navigable and TraversableNavigable are
not quite ready to call from Navigation. With this commit all of the
user-facing APIs of Navigation are in place, and the stage should be set
to implement the parts of the navigation and traversal AOs that need to
interact with the Navigation object.
