I'm using Tiny 4.9.10 to dynamically generate reports based on templates. Users can create templates which contain placeholders. These placeholders then get swapped out for their actual values when generating the actual report. The placeholders get their style (including font, which is the main issue here) from their enclosing <span>-tag.
When replacing the placeholder with their actual value, we use <br />-tags to insert new lines, since some of the placeholders are almost full reports on their own which need to be structured.
After the placeholders have all been replaced, we inject this dynamically generated content back into a Tiny editor, so as to allow users to make ad hoc changes to the content.
At this point however we noticed that the <span>-tag around a piece of generated content containing <br />-tags gets removed. This is a problem, because the style info that was enclosed in this tag gets removed as well, resulting in problems further down the line when generating a PDF.
What I've tried to work around this:
setting verify_html to false
adding +span[br]/+span[br /] to valid_children
setting forced_root_bloc to div
The first two options did nothing to help me, and while the last one looked promising, it didn't help, because even when using <div>, font info gets enclosed into a child <span>.
I know this is expected behavior, because <span> is an inline tag and so it shouldn't have <br /> tags as children, but I'm currently at a loss for a workaround which allows me to include <br /> tags into my dynamically generated content without losing the style (most importantly the font) of the parent tag.
So I solved this by replacing the <span> tags by <div> tags when we swap out the placeholders by using some regex looking for spans that enclose a <p>...<\p> or a <b />. This stops Tiny from throwing away the <span> tags when they contain either of these enclosed tags
TinyMCE considers the <span> <br /> </span> construct an empty space and deletes it in favor of optimization.
I may be late, but you can also try using this callback in the setup option to stop the editor from removing empty spans:
setup: function(editor) {
editor.on('PreInit', function() {
editor.schema.getElementRule('span').removeEmpty = false;
});
}
Related
I've recently begun as an Ops dev on an AEM project, and we have a component (a table, that has a title, some copy and a field where the author can author some HTML to represent the contents of a table, with and elements. This, for whatever reason, has to sit within a component, called ArticleContainer. The title should have an H1 tag if the table is at the top of the page, and an H2 tag if it's anywhere lower down. I've tried using data-sly-test thus:
<sly data-sly-test.topOfPage="${table.firstPosition==true}">
<h1 data-sly-test="${table.headerCopy}" class="heading fontH2 headingLinear headingThick">
<span class="tableHeadingWrapper">${table.headerCopy # context='html'}</span>
</h1>
</sly>
<sly data-sly-test="${!topOfPage}">
<h2 data-sly-test="${table.headerCopy}" class="heading fontH2 headingLinear headingThick">
<span class="tableHeadingWrapper">${table.headerCopy # context='html'}</span>
</h2>
</sly>
Now, this kind of processing has worked elsewhere where the component doesn't sit within a container, but it seems that if it's in a container it always picks up the non-topOfPage condition. I assume there might be a way to maybe do the test within the container component & pass it down into the table component? How would one go about this, or if it's not possible, is there another method by which one might achieve this?
There are two things here:
What does table.firstPosition return? You should be able to debug this in your Sling Model or POJO and probably need to adjust the logic to account for intermediary containers.
HTL/Sightly has a data-sly-element that allows you to change the HTML element based on an expression, you could make your code shorter (and easier to maintain):
<h1 data-sly-test="${table.headerCopy}" data-sly-element="${table.firstPosition ? 'h1' : 'h2'}" class="heading fontH2 headingLinear headingThick">
<span class="tableHeadingWrapper">${table.headerCopy # context='html'}</span>
</h1>
I'm using Watir WebDriver with Firefox.
Here are two asserts for the same element. The first works, but not the second:
assert_match(/Please add user to GMT/, #browser.small(:class, "error").text)
assert_match(/Please add user to GMT/, #browser.div(:class, "eight mobile-three columns").small(:class, "error").text)
I need the second assert to work, because there are 8 error messages on the page, which are presented if the user does not populate 8 mandatory fields. All 8 errors have the identical HTML. So, I need to be able to step down from the parent.
Here is the HTML:
<div class="eight mobile-three columns">
<a id="btnAddUserToGMT" class="success radius button expand error" onclick="AddUserToGMT();" data-reveal-id="addToGMT" href="#"> … </a>
<small class="error" style="margin-top:0px;">
Please add user to GMT
</small>
</div>
Here is the error message:
Watir::Exception::UnknownObjectException: unable to locate element, using {:class=>"error", :tag_name=>"small"}
C:/Ruby193/lib/ruby/gems/1.9.1/gems/watir-webdriver-0.6.4/lib/watir-webdriver/elements/element.rb:490:in `assert_exists'
C:/Ruby193/lib/ruby/gems/1.9.1/gems/watir-webdriver-0.6.4/lib/watir-webdriver/elements/element.rb:85:in `text'
C:/Documents and Settings/Asserts_01.rb:22:in `testBasic'
The complaint for the second assert is:
unable to locate element, using {:class=>"error", :tag_name=>"small"}
And yet that same using was OK for the first assert.
Problem solved.
After discussion with the developer, it appears that by some unusual manipulation of automatically generated HTML, the text of the error message appears at its correct location on the page. But the assertion must be based on a different tag, which is specified at some completely different position on the page.
For example, I was trying to assert on this code at the correct position:
<small class="error" style="margin-top:0px;">
Gender is required
</small
Even unique xPath generated by FirePath failed to find this.
What I should have asserted on was a HIDDEN tag on a completely different part of the page.
<input id="errorMsgGenderID" name="errorMsgGenderID" type="hidden" value="Gender is required" />
There were several such tags for each mandatory field that was not populated, all bunched together on the same line. They were all "input" tags, which puzzled me.
I’m working in the Moovweb SDK and am optimizing my personal desktop site for mobile.
How do I transform all my <p> tags to <div> tags? I really don't want to do it manually! Search and replace?? haha
You can use the name() function to change the name of an element. For example:
$("//p") {
name("div")
}
See it in action here: http://tester.tritium.io/bd1be4f2c187aed317351688e23f01127d26343a
Cheap way: Add p{margin:0} to your CSS, this will remove the only special styling of <p> tags making them look like <div>s.
This is only a visual effect, though. For instance, you're still not allowed to put a <form> inside a <p>, even with the above CSS. If that's what you're after, a simple search and replace will do:
Replace <p> with <div>
Replace <p␣ (left angle, p, space) with <div␣ (there's a space at the end of that one too)
Replace </p> with </div>
That should do it!
I have a large form that consists of all the input (text, checkbox, radio, etc...), I have them grouped together in a fieldset tag and a legend for each feildset. Each input has a label associated with it as well. My question is what is the best approach to display the information on one screen and take advantage of the horizontal real estate the user might or might not have?
I would love it to be all CSS with minimal (if any) table layout(s) as I think tables are for tablature data and not presentation. CSS3 and HTML5 are welcome as well.
Also I would like to have the ability to add branding as this might need to look like another site instead of the original site developed for.
What would be the best approach for this? I have the idea I would use li tags to do the horizontal look but I would like to break to the next line at the end of the screen (Think no scrolling horizontal but vertical is okay)
CSS Novice looking for design pattern advice
This is an example but I think I have around 50 fields
<!DOCTYPE HTML>
<html>
<head>
<title>Large Form</title>
</head>
<body>
<form action="">
<fieldset>
<legend>***</legend>
<label for="fname">First Name</label><br />
<input type="text" name="fname" id="fname" value="" /><br /><br />
<label for="lname">Last Name</label><br />
<input type="text" name="lname" id="lname" value="" /><br /><br />
<label for="gender">Gender</label><br />
<select name="gender" id="gender">
<option value="">-- select</option>
<option value="male">Male</option>
<option value="female">Female</option>
</select>
</fieldset>
<br />
<input type="submit" value="Submit" />
</form>
</body>
</html>
The first thing that comes to mind is that you want to remove the <br/> tags from the form. If you need vertical space, use CSS padding and margins since they're easier to change and make spacing consistent.
With that out of the way, other than branding (which will influence the look and feel of the form the most) the things you want to consider the most are accessibility and ease of use. Your use of labels and unwillingness to use tables for layout are a good start for accessibility so I'm not going to mention it further.
For ease of use, you'll need to make sure that each field can be tabbed to (in an order that makes sense), has a clear, meaningful label, has no unnecessary validation rules (such as forbidding whitespace in a phone number - don't force the user to clean data that can be cleaned automatically) and those validation rules that are necessary have clear, easy to understand messages that appear, ideally, as the user is entering the data rather than waiting for the user to submit the form.
Each of your field sets should be visually grouped either by colour, with a border or some other method. Individual field set should not be broken up, but different field sets can be separate from each other as long as they are contextually different (like address versus interests, for example).
Since you're already grouping field sets, you can use them as your basic unit of page layout. Each set could be floated, for example, in order to maximimize horizontal usage regardless of the user's browser width. As long as the sets are visually distinct enough and are clearly labelled there shouldn't really be any issues with that.
If consistency is more your thing, then each field set should be separated from each other vertically. That would make sure the form is ordered and laid out the same way for every user. Again, the important thing is visual consistency and ease of use. Users are used to forms being laid out vertically so the wasted horizontal space of doing it that way shouldn't be a very big concern.
Just remember: you're making something that should be easy to use and not frustrating. The position of fields should reflect that: they should be natural, grouping like fields together and separating groups of like fields from dissimilar fields. As long as you're keeping that in mind you're probably in good shape.
And don't forget to do some quick usability tests to make sure your validations make sense and are clear.
Have a look at CSS3 grid positioning. It has a clear but powerful syntax, e.g. from the link:
body {
grid-columns: * * (0.5in * *)[2];
grid-rows: 20% *;
columns: 3;
column-gap: 0.5in;
}
Elements use gr units to choose their grid cell:
img {
position: absolute;
left: 2gr;
width: 3gr;
}
You would only have to give an id to your fieldsets then set their position and extents in your style file.
One of my favorite ways to group large forms is with the jQuery style accordion. It allows you to abstract the form into key groupings, keep the form all on one page, and eliminate the need for page scrolling; all with an intuitive user interface.
A good example of this is the Barnes & Noble checkout form process.
Check out CSS Flexbox for some liquid flexibility withing you design sets. I would also recommend picking a "style" and sticking with it. Agree with Welbog.
I guess that if you have a form with 50 fields, you surely have to split it to themed tabs. Say 3 to 5 tabs. They can be implemented by Javascript.
You may want to save input data on-the-fly, because the user may need a long time to finish the form, so there is bigger possibility that he will catch a loss of internet connection or some other factor, that will erase his half-finished form, which would probably dissapoint him and leave your site.
Also consider that user has to have a place for his eye to rest, so be sure to make enough blank room between inputs.
I'm adding an element to a document with the following:
Element parent = getParentElement(); // Returns the right thing.
HTML html = new HTML();
html.setHTML( "<td>BLAH</td>" );
parent.appendChild( html.getElement() );
When I view the resulting document with FireBug though, the parent's child looks like this:
<div class="gwt-HTML"> BLAH </div>
I can use FireBug to add in the <td> elements manually, and all my formatting applies, etc. Does anyone know why the HTML element seems to be removing my <td> tags?
It turns out that it's FireFox that's stripping it out. If I just use plain old javascript to create a div, or a tr, and set innerHTML to be <td>BLAH</td>, it still gets stripped. A couple of others have noticed this as well: http://www.jtanium.com/2009/10/28/firefox-gotcha-innerhtml-strips-td-tags/
If I use javascript to create a <table> tag, and add it to the DOM, I can then place the <td> in that. Of course, it helpfully creates a <tbody><tr> for me as well, so I'm not really getting back what I put in....