Goal: an encapculated widget
Suppose I'm the developer of a widget showing a list of friends, such as:
Your friends Michael, Anna and Shirley love this webpage!
First approach: script that creates span
Naively, I create a script which places this information in a span on the website. However, the owners of ExampleSite can now access the names of your friends by simple DOM operations!
That's a big privacy / security issue.
Second approach: an iframe
I don't want ExampleSite to have access to their friends' names. So instead, I let website owners add the widget with an iframe:
<iframe src="http://fakebook.com/friends?page=http%3A%2F%2Fexample.org%2F"></iframe>
This works, because the owners of ExampleSite cannot scrape the contents of the iframe. However, this whole iframe thing is rather ugly, because it does not integrate into the styling of the website, while a span does.
Desired approach: Shadow DOM
When reading about Shadow Dom yesterday, I wondered whether that could be a solution to both issues. It would allow me to have a script that creates a span the original website cannot access:
var host = document.querySelector('#friends');
var root = host.webkitCreateShadowRoot();
root.textContent = 'Your friends Michael, Anna and Shirley love this webpage!';
However, **does a Shadow DOM hide its contents from the surrounding page?**
The assumption here is that nobody except my script can access `root`, but is that correct?
The Shadow DOM spec after all says that it offers functional encapsulation, but I actually want trust encapsulation. And while the Component Model Use Cases actually list this use case, I'm not sure whether Shadow DOM realizes the necessary confinement property.
It does not, but it's in the works: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
The encapsulation of trust will involve creating a new scripting context for each shadow tree, which is overkill for most scenarios. However, as the bug says, we'll add a flag (details TBD) that would allow this.
Related
I really hope I'm making sense with this one.
I'm trying to create a widget from a custom webpart that I created. It's nothing special at all as you can see:
<h3>Header</h3>
<p>Intro Copy</p>
<ul>
<li>List item one</li>
<li>List item two</li>
<li>List item three</li>
</ul>
I now want to be able to create a widget from this and create new fields that will be used to populate the above DOM. What do I need to do in order or do this.
In an example I saw for the demo site, they populated the bg image with:
style="background-image: url('{% ResolveUrl(PathToImage) %}');"
That was however done on the front facing part of the CMS and I'm trying to do it within the solution.
Any thoughts?
It's all in your layout or code behind. Your layout can have that code (but in ASCX format) and it will work just fine. OR you can add literal controls to the page based on the fields and what the user has entered.
Doing it in your layout is more restrictive and specific to that one application but allows you to use multiple new webpart layouts. Using the code approach allows you to be more dynamic but doesn't allow you to use the built-in layouts of the webpart/widget.
I would just use the Transformable Web Part in the Marketplace...it does exactly what you want it to do. Create a custom web part, and you use a Transformation to style the Web Part Properties into the DOM elements.
https://devnet.kentico.com/marketplace/web-parts/transformable-web-part
Reason why i built it!
I've done something similar in the past, using what I call generic web parts. I wrote a blog on it last year - it might help out with what I think you're trying to achieve:
http://www.mattnield.co.uk/Posts/Show/generic_web_parts_for_rapid_development
Why are you choosing to go with Widgets? If you want to access any field inside the transformation within the web part it's feasible by the same way as you define in inbuilt web parts.
If you want to perform any function like onload etc. then you need to use kentico API to access any data.
If you provide more insight on what is required, I can help further
Are Content Scripts (http://code.google.com/chrome/extensions/content_scripts.html) injected into prerendered pages (document.webkitVisibilityState== 'prerender') ?
I’ve been reading https://developers.google.com/chrome/whitepapers/prerender and https://developers.google.com/chrome/whitepapers/pagevisibility, and am trying to figure out how Content Scripts work with page prerendering/prefetching.
Thanks
TheZ, tomdemuyt: I’m afraid you guys are missing the point. ‘run_at’ specifies whether the content script is injected before or after the DOM is constructed.
However, I am talking about document.webkitVisibilityState, which can be ‘prerender’ (when the page is in a background/invisible tab), ‘hidden’, or ‘visible’. Note that webkitVisibilityState can transition from ‘prerender’ to ‘hidden’ or ‘visible’, or back and forth between ‘hidden’ and ‘visible’, without any changes being made to the DOM. (In order to better understand this, read the articles linked in my original post.)
I think I’ve been able to determine that content scripts ARE injected into prerendered pages. Here’s the problem, however: let’s say my content script does something that should not occur on a prerendered page. For instance, it does pageview count, or adds animation, neither of which should begin until the user is actually viewing the page. So it seems that my content script should do something like what’s shown in the code examples on https://developers.google.com/chrome/whitepapers/pagevisibility - check document.webkitVisibilityState, and also listen to the ‘webkitvisibilitychange’ event, and only do pageview count/start the animation when document.webkitVisibilityState is, or has transitioned to, ‘visible’.
I may have just answered my own question, but I just wanted to make sure that I was on the right track.
Thanks
As TheZ mentioned, you should ues the run_at setting.
Link to docs : http://code.google.com/chrome/extensions/content_scripts.html#registration
I have a page I'd like to embed a news-feed widget into (so that the feed from some remote site will be displayed in my site).
While there are quite a few free news-feed widgets available out there (a partial list is here: http://allwebco-templates.com/support/S_script_newsfeed.htm), They all require insertion of complex code into the html page, while all the parameters are hard-coded into the generated code, which looks something like this:
insertedWidgetText = "<script id=\"scrnewsblock10795953\" type=\"text/javascript\">...script specific parameters go here...</script>"
let feedWidget = toWidgetBody [hamlet|#{preEscapedText insertedWidgetText}|]
This doesn't integrate well with Yesod's approach as it requires specifying to Hamlet that the content is preEscapedText, which in turn disables the ability to use Hamlet's processing to alter parameters of the widget dynamically (So in case I want the widget to use a different source, for example, I need to statically change the quoted text and cannot use Hamlet's variable substitution).
Of course I could do some text manipulation myself, tailor built for the widget I'm using, but that doesn't seem like the "right" solution (especially if I want to have the embedded text in some external file and not in the middle of my code as in the example above).
Can the above mentioned issue have a better solution than the one I thought about?
Is there an implementation of a news-feed widget in Haskell/Yesod that I can use as a plugin?
Note: I'm a very poor javascript programmer, but solutions in that direction are also welcomed.
Thanks,
I have an article set up in Joomla that displays Terms and Conditions for the site users. I would like this to show up in a shadowbox when a user clicks a link. Here is the current anchor text example:
Terms and Conditions
This works out great for displaying the entire web page, but what I would like to do is just display the article text on the page (plain with a white background). Is this in someway possible with shadowbox? If so, how?
If I'm understanding you correctly - you want to suppress the modules and other periphery from your 'page' when it is loaded in the shadowbox.
Add ?tmpl=component to the url of your link.
You can do this with a div element and css shadow effect.
How to show/hide div is explained here:
http://www.randomsnippets.com/2008/02/12/how-to-hide-and-show-your-div/
How you can add shadow is explained here:
http://placenamehere.com/article/384/css3boxshadowininternetexplorerblurshadow/
I believe there are some components to do this - but you may have to get creative to do it without pulling the whole page with an a href tag.
In the database there's a particular area that holds that specifically and you could write a little query to just pull that information specifically and put it in the shadowbox, but what that query would look like I'm not sure.
At the top of many pages in our web application we have error messages and notifications, 'Save' and other buttons, and then our h1 tag with the content title. When making a web application accessible, is it ever acceptable to have content above the top-level structure tag like we do here?
As a screen reader user I don't like content above the main heading. Normally I navigate by headings so would miss the error message. A better solution is to output an h1 heading above the error message, then leave the rest of your headings in tact giving you two h1 headings.
Yes (you can put stuff above them). The H simply means Heading. It's a question of what the heading relates to I guess.
My only caveat is, H2 shouldn't really be above H1, and H3 Shouldn't be above H2. But I don't think it's an actual rule.Websites have menus, warning, notifications. It's acceptable to put them above the rest of your content. I don't see how it would affect accessibility as long as your content is ordered logically. Look at the page CSS turned off. Does it look logical? That's the most important part of accessibility.
Although some people do go that extra mile and have the menu as the last item in the markup and use CSS to bring it back to the top. Personally, I find that solution counter productive. The menu is still important, it belongs at the top of the page.
Yes, just consider it is in that order that the user will get the information. So, if you just did an operation it sounds like a good idea to get any message related to it as the first thing. If it is a notification that appears on any page unrelated to what you are doing, I wouldn't put it above, as it might be a little weird.
Also you can use a text browser that doesn't use styles, it should look like a document with appropriate headers.
Heading tags are used to indicate the hierarchy of the content below it. You should only have one h1 tag and it should be the first content to appear on your page (this is usually the name of the site). Also, you shouldn't skip heading tags when drilling down through different tiers of content.
In your case, you can still use CSS to position items above the h1 tag as long as it is in the correct order in the html.
I assume the elements above the heading are used by JavaScript. In that case, it's preferable if they are created by JavaScript, not included in the source of the page.
To return to your original question, it is probably best that they be at the foot of the page. However, if they are hidden using the CSS "display: none;" or "visibility: hidden;" properties then they will not be seen by most (perhaps all?) screenreaders or by many other assistive technologies, and so should not be an issue. I've written a fairly detailed explanation of why accessibility technology ignores such elements.
Of course if somebody disables CSS things are going to look pretty messy. If there is content on the page that can be used even when CSS and/or JavaScript are disabled, then putting those elements at the bottom of the page will at least make things less cluttered.