Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for form owner #249

Merged
merged 1 commit into from
Feb 6, 2017
Merged

Conversation

canova
Copy link
Contributor

@canova canova commented Jan 23, 2017

This is rebased version of #137. Fixed merge conflicts, updated to current codebase and addressed some comments. But there are still some todo's needs to be addressed. Servo side of this changes is currently WIP. Opening this for early feedbacks.


This change is Reviewable

@canova
Copy link
Contributor Author

canova commented Jan 23, 2017

r? @jdm

@jdm jdm self-assigned this Jan 23, 2017
bors-servo pushed a commit to servo/servo that referenced this pull request Jan 31, 2017
Implement the form owner concept

<!-- Please describe your changes on the following line: -->
Implemention of the core logic for form owners. It's rebased version of #6613, addressed most of the comments and fixed some of the code. I needed to update the code by hand instead of rebasing old main commit because of the massive merge conflicts over the years.

The html5ever PR is here: servo/html5ever#249

Currently I'm using my html5ever fork to run the tests. I'll undo the changes in Cargo.toml and Cargo.lock once it gets merged.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #3553 (github issue number if applicable).

<!-- Either: -->
- [X] There are tests for these changes

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/15283)
<!-- Reviewable:end -->
Copy link
Member

@jdm jdm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! Most of my comments are just about clarifying documenation or names of things to match the current specification text better.

@@ -72,6 +72,10 @@ pub trait TreeSink {
/// Do two handles refer to the same node?
fn same_node(&self, x: Self::Handle, y: Self::Handle) -> bool;

/// Are two handles present in the same tree
/// https://html.spec.whatwg.org/multipage/infrastructure.html#home-subtree
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This link isn't valid any more. The text in step 12 of https://html.spec.whatwg.org/multipage/syntax.html#create-an-element-for-the-token just says "same tree" with a link to https://dom.spec.whatwg.org/#concept-tree; we can probably just name this same_tree in that case.

@@ -775,10 +743,39 @@ impl<Handle, Sink> TreeBuilderActions<Handle>
// FIXME: application cache selection algorithm
}

// https://html.spec.whatwg.org/multipage/syntax.html#create-an-element-for-the-token
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove syntax.html. However, we really will need comments labelling which steps are being implemented in the code, because it's really hard to figure out the association. I guess the majority of the new code is in support of the form owner stuff in step 12?

BeforeSibling(ref p) => p.clone()
};

// Step 4.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This step number is wrong.

if form_associatable(qname.clone())
&& self.form_elem.is_some()
&& !(reassociatable(qname.clone())
&& attrs.iter().any(|a| a.name == qualname!("","form"))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: && belongs on the previous line in all these cases.

@@ -747,7 +747,7 @@ impl<Handle, Sink> TreeBuilderActions<Handle>
fn insert_element(&mut self, push: PushFlag, ns: Namespace, name: LocalName, attrs: Vec<Attribute>)
-> Handle {
declare_tag_set!(form_associatable =
"button" "fieldset" "input" "keygen" "label"
"button" "fieldset" "input" "keygen" "label" "legend"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, legend element's tests were not passing without this change. But maybe I missed something I'll look into that.

// TODO: Handle template element case
if form_associatable(qname.clone())
&& self.form_elem.is_some()
&& !(reassociatable(qname.clone())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear why we're using reassociatable instead of the definition of listed here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think its name is changed since 2015. They weren't different except names. I renamed it that way.

};

// Step 12.
// TODO: Handle template element case
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's required to handle this? We support template elements elsewhere in the parser now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're right. I forgot about it. Implemented it now, but I need to be sure that it's right :) https://html.spec.whatwg.org/multipage/syntax.html#create-an-element-for-the-token step 12 says:

...and there is no template element on the stack of open elements...

I hope I understand it right.

@jdm
Copy link
Member

jdm commented Feb 6, 2017

If you squash the commits, I'll merge them. Thanks!

@canova
Copy link
Contributor Author

canova commented Feb 6, 2017

Squashed it. Thanks for the help!

@KiChjang
Copy link
Contributor

KiChjang commented Feb 6, 2017

@bors-servo r=jdm

@bors-servo
Copy link
Contributor

📌 Commit 69f7069 has been approved by jdm

@bors-servo
Copy link
Contributor

⌛ Testing commit 69f7069 with merge dfeb635...

bors-servo pushed a commit that referenced this pull request Feb 6, 2017
Implement support for form owner

This is rebased version of #137. Fixed merge conflicts, updated to current codebase and addressed some comments. But there are still some todo's needs to be addressed. Servo side of this changes is currently WIP. Opening this for early feedbacks.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/html5ever/249)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

☀️ Test successful - status-travis
Approved by: jdm
Pushing dfeb635 to master...

@bors-servo bors-servo merged commit 69f7069 into servo:master Feb 6, 2017
@canova canova deleted the form-owner branch February 6, 2017 20:43
bors-servo pushed a commit that referenced this pull request Feb 14, 2017
Revert "Implement support for form owner"

This reverts commit 69f7069 (#249).

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/html5ever/252)
<!-- Reviewable:end -->
@jdm
Copy link
Member

jdm commented Feb 15, 2017

We're going to need to make a new PR to merge this when servo/servo#15283 is ready to merge.

@nox
Copy link
Contributor

nox commented Mar 13, 2017

@canaltinova Was there really no way to avoid separating the concept of appropriate place for insertion and the insertion itself?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants