Is there a way to select elements that have text that is truncated due to the CSS overflow text-overflow: ellipsis; settings?
<div>
<span>Text 1</span><br>
<span>Text 2</span><br>
<span>Text Item Trunca...</span> <-- Select this?
</div>
The purpose would be for selecting items that are truncated in order to display the entire text in something like a Bootstrap tooltip:
$("div span:hidden?").tooltip();
Related
I want to test that the text "Name contains Referencia", that I show in the image, appears in a textarea; this text appears as a result of doing a filter action over a data area. However in the DOM this text is not shown. Could anybody explain why it isn’t shown? and how can I get that specific text if I don't have a locator?
I've tried this:
cy.get('textarea[name="cdFilter"]')
.click()
.then(()=>{
cy.contains('(Name contains Referencia)').should('exist')
})
but it doesn't work. I've tried also getting the text attribute from the textarea element but it doesn't make sense since the textarea doesn't have a text attribute.
I appreciate your help and comments.
Thanks in advance!
<td align="left" class="formCell" style="" id="isc_1S" $89="isc_TextAreaItem_1"><textarea name="cdFilter" id="isc_1T" $89="isc_TextAreaItem_1" $9a="$9b" class="textItem" style="resize:none;margin:0px;WIDTH:234px;HEIGHT:96px;" autocomplete="OFF" spellcheck="true" wrap="SOFT" tabindex="2305" oninput="isc_TextAreaItem_1.$43g()" readonly="TRUE" handlenativeevents="false"></textarea>
</td>
It could be in shadow DOM, in which case add includeShadowDom: true to your cypress.json config file and the test might succeed.
The text is definitely not in the textarea element, but it could be another element positioning itself over the text area.
Couple of other things to try
Shorter text search in case the spaces are nbsp
cy.contains('Referencia')
Grab the textarea by id and look at it's text
cy.get('textarea#isc_1D').its('text')
.should('contain', 'Referencia')
//or
.then(text => console.log(text))
There may also be two of these textareas - if you look at style details, they don't quite fit, e.g style attribute width and height don't quite match the numbers in the tooltip, and a small margin is showing even though margin:0px is set (but may be that's due to <td> settings).
Checking how many textareas:
cy.get('textarea[name="cdFilter"]').click()
.then(() => {
// test count after clicking
cy.get('textarea[name="cdFilter"]').then($ta => console.log($ta.length))
})
Hello I'm getting crazy around a dummy problem: how to remove paragraph tags < p > that RTE (in Typo3 6.1.7) adds oafter saving some text contents. I wish to add some images here to better explain this funny thing but I can't since I've not (yet) enough reputation.
BTW I put the images on an external site:
http://s16.postimg.org/uqbu40fut/rte_ptags_1.jpg
http://s16.postimg.org/7q56roi11/rte_ptags_3.jpg
The first image is a text entered in RTE; the second image (not shown here for the same reputation matter) is the same text shown in the "<>" raw view; the last image is what I see in raw view AFTER saving the content element.
I think that I must do something in the template or in the Typoscritp settings to remove these < p > useless tags... But what ??
Those <p> tags are enabled by default because in most cases you want your Text wrapped in propper HTML markup. However, typing your question into google, gets me to this two lines of Typoscript, wich I just tested on a 6.1.7 and which seem to do the job:
tt_content.stdWrap.dataWrap >
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines >
// Remove Class Of <p class="bodytext">
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.addAttributes.P.class =
// Remove P tag
tt_content.stdWrap.innerWrap >
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines >
//Remove Extra Figure Tag of Image
tt_content.image.20.renderMethod = figure
tt_content.image.20.rendering.figure
I'm designing a form like this, where the bottom of the labels in that row align in straight line and the top of the input fields in that row align in straight line.
Owing to some restriction in CSS (we can't fix the height as it will vary), I've to place the labels of the form elements in first row and then place their respective input fields in the next row (such that the input fields are placed just below their labels).
I tested the keyboard & the tab order with this html structure, it works fine.
I'm wondering that the reading order in JAWS or any other screen reader is not going to be right.
Any recommendations for any method to change the reading order
or
is it ok to go ahead with this html structure since the tab order is anywys working ?
In the HTML structure each input should be preceded by its label, rather than having labels on one row and inputs on the next.
However, you have a very particular display you want, and you are supporting IE7 (without display: table), so I think you are best off actually using a table.
You can do this accessibly, if you take these things into account:
Use a basic layout table for your form, and include an extra attribute on the table tag:
<table role="presentation">
That means the table is not a table from an accessibility point of view. (I only ever recommend this when supporting IE7 layouts!) Do not use <th> tags either.
The main thing for screen readers when filling it in would be an explicit label-input relationship.
<label for="input_id">My label</label>
<input type="text" id="input_id">
You can tell if this works by clicking on the label, it should put the cursor in the input.
However, your reading view needs a different approach. When you've got a row of items at the top that relate to a row of items underneath, that is the definition of a data table. So when the page is saved (or however it converts to the reading view), use a data table e.g:
<table>
<tr>
<th>Customer account number</th>
[other <th>s]
</tr>
<tr>
<tr>
<td>023456353434</td>
...
When read out by a screen reader it will read the 'header' (e.g. customer account number) before the content (023...). So the changes are:
Remove the role
Convert the top row into <th>s
It has to be said this is a hack, it is not particularly robust, and I certainly wouldn't recommend it for a responsive site. It is purely the required layout and browser support that lead to this.
without viewing your markup its impossible to tell exactly, but it sounds like you have a tow of inputs and then a row of labels....that's not ideal for accessibility.
you could nest the form control inside the label element, setting the form control's display to block to achieve the same effect, while also increasing usability and clickability.
I use
and set the page setup of .rpt
- I checked the No printer option and Dissociate formatting page size
- I chose User Defined Size in dropdown
- I set Unit in pixel (Horizontal: 1200px, Vertical: 816px)
But the report viewer still still shows Letter size and the remaining Columns are not being Displayed ...
you can use Cross-Tab on crystal report so that the page width will automatically adjust depends on number of column.
Interesting question!
I suggest forcing via javascript the width of elements in your page.
A script like this should work (the name of the elements could change, inspect you HTML),
//execute when page is displayed on screen
$(document).ready(function () {
$("#CrystalReportViewer1_toptoolbar").css("width", 1200);
$("#CrystalReportViewer1__UI").css("width",1200));
}
don't foget to add jquery
<asp:ScriptManager ID="ScriptManager1" EnableScriptGlobalization="true" EnableScriptLocalization="true" runat="server" AllowCustomErrorsRedirect="true">
<Scripts>
<asp:ScriptReference Path="~/Scripts/jquery.js" ScriptMode="Auto" />
</Scripts>
</asp:ScriptManager>
I'm working on a site in EPiServer, and whenever I create a page property with the type set to "XHTML string" (which uses the WYSIWYG content editor in Edit mode), it wraps all content in <p> tags.
Is there any way to prevent this from happening? I can't remove the paragraph margins universally through my CSS (e.g. p {margin: 0 !important;}) since I do need the margins for actual paragraphs of text. I've even tried going to the HTML source view in the editor and manually deleting the <p> tags that it generates, but it immediately adds them back in when I save!
It doesn't happen when the property type is either a long or short string, but that's not always an option since the content might contain images, dynamic controls, etc.
This is becoming a real nuisance since it's very hard to achieve the layout I need when basically every element on the page has extra margins applied to it.
As Johan is saying, they are there for a reason - see more info here. That being said, it's not impossible to remove them. It can be done in one of two ways (taken from world.episerver.com:
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
myEditor.InitOptions["force_p_newlines"] = "false";
}
or
<script type="text/javascript">
tinyMCE.init({
force_p_newlines: false
});
</script>
You can add your own custom TinyMCE-config that removes P-elements or strip them out using regular expressions either when saving the page or when rendering the property/page.
I think it's a bad idea though. P-elements are what the editors generate the most and in most cases their content is also semantically correct. Better to wrap your property in a div with a class and adjust margins using CSS like you mention.
If you're using a version of EPiServer with TinyMCE editors, you can insert <br /> elements instead of <p> elements if you type shift-enter instead of enter. This should eliminate your margin problems.
More info at the link below:
http://www.tinymce.com/wiki.php/TinyMCE_FAQ#TinyMCE_produce_P_elements_on_enter.2Freturn_instead_of_BR_elements.3F
EDIT: My comment below answers his question better.
I discovered that while I can't remove the <p> tags from the source view (because it adds them back in automatically), if I replace them with <div> tags, it'll leave things alone. It does mean that I've got an extra <div> wrapping some elements that I don't really need, but at least a <div> doesn't add margins like a <p> does, so...good enough!