1. Using the struct/enum combo that I suggested in the previous email,
you would only need a vector of SourcedName, since the element is
included in the struct. You are correct that this corresponds with the
description of the specification for `sourced names`.
2. That code snippet looks like it's got the right idea, yes. As for the
image candidates, you can use `if child.is::<HTMLImageElement>()`.
3. Uncommenting the named getter in the HTMLFormElement WebIDL yields
two new methods that need to be implemented in htmlformelement.rs -
supported_property_names and NamedGetter. These correspond with two
operations - getting the list of all meaningful property names for a
HTMLFormElement object, and getting the value of a specific property
name. Adding an entry to the `past names map` happens in step 5 of
"determine the value of a named property", which will be implemented in
NamedGetter.
The past names map is a map (ie. HashMap) from a DOMString (which holds
an element's id/name value) to Dom<Element>. At the point when
NamedGetter is invoked with a string value and there is a unique form
element whose name matches the provided string, you will add an entry to
the past names map to represent that this mapping exists. This allows
the following JS code to succeed (given this HMTL: <form><input
id="first"></form>)
let form = document.querySelector('form');
let elem = document.querySelector('#first');
console.log(form.first === elem); // expected: true
elem.id = "second";
console.log(form.first === elem); // expected: true
console.log(form.first === form.second); // expected: true
(I created
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7498 to
demonstrate this, with console.log replaced with w() to use the provided
in-page log).
So both NamedGetter and SupportedPropertyNames are expected to read from
the past names map, but only NamedGetter is expected to modify it. Does
that answer your question?
Cheers,
josh
On 12/1/19 6:01 PM, Chintan Gandhi wrote:
Hi Josh,
Sorry to bother you on a Sunday.
We have added the enum and struct modifications as mentioned above. Listed
below are some issues which we are unclear about:
*1.* As mentioned on the project page, we need to create a *vector*
*(SourcedName,
DomRoot<HTMLElement>)* by iterating over *self.controls* member. This
*vector* is to be used as an *ordered list of structs (string, element,
source)* as specified in step 1 of the spec
<https://html.spec.whatwg.org/multipage/forms.html#the-form-element:supported-property-names>,
right? >
*2.* Currently, we have considered the *vector (SourcedName,
DomRoot<HTMLElement>)* as the *ordered list of structs (string, element,
source)* that we will return as the method output. This snippet iterates
over all the control elements and checks if it is a listed element. We
change the source based on the attribute the child element has and push the
entry to the *vector*. Kindly review the code and let us know if there are
any issues in the code.
* let controls = self.controls.borrow(); // borrow immutable
`controls` member for child in controls.iter() { if
child.is_listed_element() { if
child.has_attribute(&local_name!("id")) { let entry =
SourcedName {name: child.get_string_attribute(&local_name!("id")), element:
child, source: Id}; vec.push(entry, child);
} else if child.has_attribute(&local_name!("name")) {
let entry = SourcedName {name:
child.get_string_attribute(&local_name!("name")), element: child, source:
Name}; vec.push(entry, child); }
} }*
For step 3 related to image buttons, the function call *if
child.is_listed_element()* is replaced by *if
child.get_string_attribute(&local_name!("type")) == "image" **.*
*3.* In which function do we add the entries in the map and how do we
implement the past names map exactly? We read through the issue but
couldn't understand exactly the way in which we will implement it.
These are a lot of questions but we would greatly appreciate your
inputs. Thank you.
Regards
Chintan Gandhi
NC State University
On Thu, Nov 28, 2019 at 10:31 AM Josh Bowman-Matthews <j...@joshmatthews.net>
wrote:
Great question! I recommend representing it like:
enum SourcedNameSource {
Id,
Name,
Past(Duration)
}
struct SourcedName {
name: String,
element: DomRoot<Element>,
source: SourcedNameSource,
}
This will allow you to access the values that are always present as
named fields of the entry, and then use the `match` language feature to
access the values that can change depending on what kind of source it is.
For fetching the id and name attribute values, you will need the
Element::get_string_attribute API
(
https://doc.servo.org/script/dom/element/struct.Element.html#method.get_string_attribute),
and you will pass a value like `&local_name!("id")`.
Cheers,
Josh
On 11/28/19 2:07 AM, Chintan Gandhi wrote:
Hi Josh,
Greetings!
We are currently working on the named getter implementation by
following the spec and the steps you listed on the project page:
https://github.com/servo/servo/wiki/Missing-DOM-features-project.
There a couple of questions related to the SupportedPropertyNames method
implementation:
1. What should be the type of elements in the sourced names enum? The
spec says to set the source as id, name, past based on the type of
attribute it has. Would these be elements of enum be strings or of
some
other data type? Currently, the enum is defined as follows:
2. // source types enum
enum SourcedNamesStates {
"id",
"name",
"past",
}
3. How do we fetch the value of id or name attribute? We cannot seem
to
find a way to do it.
Hoping to hear from you soon. Thank you. Have a happy Thanksgiving.
Regards
Chintan Gandhi
NC State University
On Sat, Oct 26, 2019 at 4:51 PM Chintan Gandhi <cagan...@ncsu.edu>
wrote:
Hello Josh,
We are currently working on the *srcdoc iframe* issue and have made some
changes to the files: *components/script_traits/lib.rs
<http://lib.rs>,
components/script/dom/webidls/HTMLIFrameElement.webidl, components/script/
script_thread.rs
<http://script_thread.rs> *as specified in the bullet points 2, 3, 4, 5
of the *initial steps* section on the project site.
How do we test the changes that we have made? Do we simply verify our
changes by running this test: ./mach test-wpt
tests/web-platform-tests/html/semantics/embedded-content/the-iframe-element/srcdoc_process_attributes.html
or
do we need to build servo again?
If we are building servo to test the changes, do we rebuild servo
from scratch or only some specific crates?
If anything else is required to be done or you need more information on
our work, kindly let us know.
Thanking you. Hoping to hear from you soon.
Regards
Chintan Gandhi
NC State University
On Wed, Oct 16, 2019 at 2:49 PM Josh Bowman-Matthews <
j...@joshmatthews.net> wrote:
Oh, I just looked at the project page and I could see why the
descriptions of the missing DOM features might be lacking some
description. The issue link for srcdoc iframes was to the wrong issue;
sorry. I have updated the page to point at
https://github.com/servo/servo/issues/4767 instead, which contains
some
more helpful links to the specification and explanatory documents.
As for named form getters, given an HTML document like:
<form>
<input id="name">
<input name="password" type="password">
</form>
It is legal to write JS that does something like:
let form = document.querySelector('form');
let the_name = form.name;
let the_password = form.password;
Even though the 'name' and 'password' members are not part of the
HTMLFormElement interface
(https://html.spec.whatwg.org/multipage/forms.html#the-form-element),
the presence of a "named getter" in the interface describes how the web
platform should interpret an arbitrary property name
(https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem
).
Our engine does not support this yet, so part of this project is
designed to implement it.
Cheers,
Josh
On 10/16/19 2:40 PM, Josh Bowman-Matthews wrote:
Welcome! Could you be more specific about what kind of clarification
you're looking for? What parts of the project description page are
unclear right now?
Cheers,
Josh
On 10/16/19 2:13 PM, Chintan Gandhi wrote:
Hello All,
Greetings!
We, Chintan Gandhi, Jay Modi and Anshul Jethvani are grad students at
NC
State University and will be working on the missing DOM features
project.
We would be following this web page
https://github.com/servo/servo/wiki/Missing-DOM-features-project in
order
to move forward with the project.
It would be really helpful if you could clarify the project
definition
and
throw some more light on the DOM features missing in Servo.
The steps that we plan to take are:
1. Build Servo on our machines using the guide mentioned on the above
website.
2. Follow the initial and subsequent steps mentioned on the above
site.
Looking forward to making useful contributions.
Regards,
Chintan Gandhi
Jay Modi
Anshul Jethvani
NC State University
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
