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 src attribute for popovers #1780

Merged
merged 27 commits into from
Mar 10, 2022

Conversation

jovyntls
Copy link
Contributor

@jovyntls jovyntls commented Feb 16, 2022

What is the purpose of this pull request?

  • Documentation update
  • Bug fix
  • Feature addition or enhancement
  • Code maintenance
  • Others, please explain:

Resolves #59

Overview of changes:
Implements the src attribute in popovers, which allows popover contents to be loaded from other files.

Anything you'd like to highlight / discuss:

  1. Static vs dynamic approach
  2. Behaviour on conflicting slots/attributes
    • Currently, popover contents can be given through 3 ways. I used the following 'priority' of overriding:
      1. content slot
      2. src attribute
      3. content attribute
    • Rationale: For other MarkBind components, slots are taken as the highest 'priority' and an attribute will be overwritten/ignored if the corresponding slot is provided. Though I'm not sure if src attribute should override content slots in this case?

Testing instructions:

<popover header="Content loaded from src" src="{{ baseUrl }}/userGuide/syntax/extra/loadContent.html#fragment">
	Hover
</popover>

Proposed commit message: (wrap lines at 72 characters)

Implement src attribute for popovers

Content can be supplied to popovers through either the content slot, or
content attribute.

Manually providing popover contents may be inconvenient if an author
wants to reference content from elsewhere on the site. 

Let's implement the src attribute for popovers, so that authors can
reference content from source files. This is more convenient for
authors, while helping to ensure consistency in website contents.

Using the src attribute maintains consistency with other components such
as Panels and Includes, which also use src.

The src attributed was implemented with a static approach to avoid
potential positioning issues. In the case that multiple contents are
supplied, the following priority is used: content slot > content
attribute > src attribute

Checklist: ☑️

  • Updated the documentation for feature additions and enhancements
  • Added tests for bug fixes or features
  • Linked all related issues
  • No unrelated changes

@jovyntls jovyntls marked this pull request as ready for review February 17, 2022 00:41
Copy link
Contributor

@tlylt tlylt left a comment

Choose a reason for hiding this comment

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

Great job!
One slight clarification:
Does the src allows for both a html page URL and a markdown file (just like the include mechanism)?
If so perhaps we could mention both and give one example each.

Also there's a conflict due to the latest PR merge.

PS. one more question in mind:
Just curious, does the importing of content from an external URL leads to a potential XSS attack, or has it already been handled accordingly?

@jovyntls
Copy link
Contributor Author

jovyntls commented Feb 19, 2022

@tlylt Thanks for looking through!

Great job! One slight clarification: Does the src allows for both a html page URL and a markdown file (just like the include mechanism)? If so perhaps we could mention both and give one example each.

Yup! Good idea, I'll add it to the docs

Also there's a conflict due to the latest PR merge.

Fixed, thanks for the catch :)

PS. one more question in mind: Just curious, does the importing of content from an external URL leads to a potential XSS attack, or has it already been handled accordingly?

By external URL, do you mean something like src="{{baseUrl}}/hello.html"? For this, XSS is possible though there's currently no warning given for users. I'm not sure if this will be a threat though, since these files are usually supplied by the user themselves?

@tlylt
Copy link
Contributor

tlylt commented Feb 19, 2022

By external URL, do you mean something like src="{{baseUrl}}/hello.html"? For this, XSS is possible though there's currently no warning given for users. I'm not sure if this will be a threat though, since these files are usually supplied by the user themselves?

Ok, I think I had the wrong impression that the src could be any URL to an HTML page on the web but I think it doesn't seem to be the case. Hence maybe it's not that necessary to give any warnings at the moment.

@ryoarmanda
Copy link
Contributor

ryoarmanda commented Feb 20, 2022

Thanks for the work, @jovyntls ! Review is underway.

  • Currently, popover contents can be given through 3 ways. I used the following 'priority' of overriding:
    a. content slot
    b. src attribute
    c. content attribute
  • Rationale: For other MarkBind components, slots are taken as the highest 'priority' and an attribute will be overwritten/ignored if the corresponding slot is provided. Though I'm not sure if src attribute should override content slots in this case?

Let's discuss about the priority list. Just my 2 cents, how about if we put src attribute last? This is under the assumption that users would normally do just one of these three, which is a reasonable use-case and what is exampled in the issue.

It's a little bit unintuitive to think src will be overridden by content, but I like to think that just like a general scoping rule, the closest specified content should "win". In this case, it means content that is supplied directly when writing the popover component, which is either through the content attribute or the content slot (we can follow suit with other components and let the slot win if both are defined). The content specified in src is an externally-defined content wrt. the page and "loses" to those. If the user wishes to display that, however, they can just not write the content stuff (I guess it's a reasonable ask). What do you think?

@jovyntls
Copy link
Contributor Author

@ryoarmanda
I like the idea of using "scoping" here - I think while src overriding content is more intuitive, using some sort of rule (scoping) would be better than the intuitive approach in case we need to standardise behaviour in the future.

Copy link
Contributor

@ryoarmanda ryoarmanda left a comment

Choose a reason for hiding this comment

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

Okay then, we can set the priority as discussed. In the meantime, here are some improvements that can be made for your implementation (the tests and docs reviews are to be done later when the implementation is solid). Feel free to address this alongside modifying the priority :)

P.S. don't forget to sync with master!

packages/core/src/html/includePanelProcessor.js Outdated Show resolved Hide resolved
packages/core/src/html/includePanelProcessor.js Outdated Show resolved Hide resolved
packages/core/src/html/includePanelProcessor.js Outdated Show resolved Hide resolved
packages/core/src/html/includePanelProcessor.js Outdated Show resolved Hide resolved
+ `Missing reference in ${context.cwf}`);
logger.error(error);

actualContent = cheerio.html(createErrorNode(node, error));
Copy link
Contributor

Choose a reason for hiding this comment

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

This way, the error node I think would be in the tooltip content 😄 (let me know if this is correct and/or intended). If not, we can adopt the way to replace the node with error node like in the above lines and early return.

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 used the same behaviour as include - i.e., when the src is invalid, it displays the error node:
image

Though on thinking further, I think it's a better idea to log the error, and not display the node instead 😅
Is this behaviour desirable for include too?

packages/core/src/html/MdAttributeRenderer.js Outdated Show resolved Hide resolved
@jovyntls
Copy link
Contributor Author

Thank you so much for the detailed look-through @ryoarmanda ! I've made the changes and re-synced with master.

Copy link
Contributor

@ryoarmanda ryoarmanda left a comment

Choose a reason for hiding this comment

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

Thanks for the follow up! Here are some reviews that we can work on:

packages/core/src/html/elements.js Outdated Show resolved Hide resolved
packages/core/src/html/vueSlotSyntaxProcessor.js Outdated Show resolved Hide resolved
Copy link
Contributor

@ryoarmanda ryoarmanda left a comment

Choose a reason for hiding this comment

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

Thanks for addressing the review! The implementation is pretty solid (with one very minor change below) and all that's left is coming up with the tests and cleaning up the documentation 😄

packages/core/src/html/includePanelProcessor.js Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
docs/userGuide/syntax/popovers.md Show resolved Hide resolved
@jovyntls
Copy link
Contributor Author

jovyntls commented Mar 6, 2022

Thanks again @ryoarmanda for the detailed lookthrough! I've made the changes mentioned, and also made an additional change to packages/vue-components/README.md since I realised it hadn't been updated yet.

@tlylt
Copy link
Contributor

tlylt commented Mar 7, 2022

Just checking, does this part in coreesrc/html/linkProcessor.js need to be updated as well?
image

@jovyntls
Copy link
Contributor Author

jovyntls commented Mar 7, 2022

@tlylt Thanks for the catch!

You're right, defaultTagLinkMap is used in convertRelativeLinks so popovers should be included as well, otherwise relative links won't work for the src attribute. I originally thought it wasn't needed since validateIntraLink returns immediately, didn't realise that convertRelativeLinks uses this as well.

Copy link
Contributor

@ryoarmanda ryoarmanda left a comment

Choose a reason for hiding this comment

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

Just some little documentation nits before ready to approve!

docs/userGuide/syntax/popovers.md Outdated Show resolved Hide resolved
packages/vue-components/README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@ryoarmanda ryoarmanda left a comment

Choose a reason for hiding this comment

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

LGTM! 🎉

@ryoarmanda ryoarmanda added this to the 4.0 milestone Mar 9, 2022
@ryoarmanda
Copy link
Contributor

Hi @jovyntls , before I merge the changes, let's add more information to the commit message, as this is a considerable popover enhancement.

@jovyntls
Copy link
Contributor Author

Thanks for the reminder @ryoarmanda ! I've updated the commit message to include more information.

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.

Allow src attribute for popovers
3 participants