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
