This patch moves the CSS property+value storage down to a new subclass
of CSSStyleDeclaration called PropertyOwningCSSStyleDeclaration.
The JavaScript wrapper for CSSStyleDeclaration now calls virtual
functions on the C++ object.
This is preparation for supporting computed style CSSStyleDeclaration
objects which won't have internal property storage, but rather an
internal element pointer. :^)
The spec allows us to optionally return from these for any reason.
Our reason is that we don't have all the infrastructure in place yet to
implement them.
Since we can't simply give HTML::EventLoop control of the whole program,
we have to integrate with Core::EventLoop.
We do this by having a single-shot 0ms Core::Timer that we start when
a task is added to the queue, and restart after processing the queue and
there are still tasks in the queue.
The DOM specification says that the primary use case for these is to
give Promises abort semantics. It is also a prerequisite for Fetch,
as it is used to make Fetch abortable.
a
This is a bit hackish, but this way the existance of the calc()
becomes transparent to the user who just wants a Length and doesn't
care where it came from.
While structs being forward declared as classes is not strictly an
issue, Clang complains as this is not portable code, since some ABIs
treat classes declared as `class` and `struct` differently.
It's easier to fix these than to reason about explicitly disabling
another warning.
This allows you to invoke the HTML document parser and retrieve a
document as though it was loaded as a web page, minus any scripting
ability.
This does not currently support XML parsing.
This is used by YouTube (or more accurately, Web Components Polyfills)
to polyfill templates.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
The WebSocket bindings match the original specification from the
WHATWG living standard, but do not match the later update of the
standard that involves FETCH. The FETCH update will be handled later
since the changes would also affect XMLHttpRequest.
HTMLCollection is an awkward legacy interface from the DOM spec.
It provides a live view of a DOM subtree, with some kind of filtering
that determines which elements are part of the collection.
We now return HTMLCollection objects from these APIs:
- getElementsByClassName()
- getElementsByName()
- getElementsByTagName()
This initial implementation does not do any kind of caching, since that
is quite a tricky problem, and there will be plenty of time for tricky
problems later on when the engine is more mature.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
To implement the HttpOnly attribute, the CookieJar needs to know where a
request originated from. Namely, it needs to distinguish between HTTP /
non-HTTP (i.e. JavaScript) requests. When the HttpOnly attribute is set,
requests from JavaScript are to be blocked.
This moves the cookie parsing steps out of CookieJar into their own file
inside LibWeb. It makes sense for the cookie structures to be in LibWeb
for a couple reasons:
1. There are some steps in the spec that will need to partially happen
from LibWeb, such as the HttpOnly attribute.
2. Parsing the cookie string will be safer if it happens in the OOP tab
rather than the main Browser process. Then if the parser blows up due
to a malformed cookie, only that tab will be affected.
3. Cookies in general are a Web concept not specific to a browser.
A label's format is: <label>Label text</label>
So, a TextNode is created as a child of the Label node, and EventHandler
will send events to the TextNode. This changes TextNode to accept mouse
events if its parent is a Label, and to forward those events upward.
The HTML <label> element is special in that it may be associated with
some other <input> element. When the label element is clicked, the input
element should be activated.
To achieve this, a LableableNode base class is introduced to provide an
interface for "labelable" elements to handle mouse events on their
associated labels. This not only allows clicking the label to activate
the input, but dragging the mouse from the label to the input (and vice-
versa) while the mouse is clicked will also active the label.
As of this commit, this infrastructure is not hooked up to any elements.
This patch adds bindings for the following objects:
- StyleSheet
- StyleSheetList
- CSSStyleSheet
You can get to a document's style sheets via Document.styleSheets
and iterate through them using StyleSheetList's item() and length().
That's it in terms of functionality at this point, but still neat. :^)
Document and HTMLElement now inherit from HTML::GlobalEventHandlers
which allows them to support "onfoo" event handler attributes.
These are assignable both via IDL attributes and content attributes.
Event listeners constructed this way get a special "attribute" flag
on them so we know which one to replace if you reassign them.
This also allows them to coexist with EventTarget.addEventListener().
This is all a bit sloppy, but it works decently for a first cut.
The Window object should also inherit GlobalEventHandlers, but since
we don't generate it from IDL, I haven't taken that step here.
Also this would be a lot nicer if we supported IDL mixins.
Just have all the timing functions return 0 for now.
We can now run the Shynet JS on https://linus.dev/ although the XHR
is rejected by our same-origin policy.
