As per an user-request I'm trying to make my (PhoneGap) webapp work better with RTL languages, such as Hebrew. I want to make my inputs and textareas work better with these languages. When the user switches their keyboard to such a language, the input direction automatically switches to right-to-left, as intended. However, the text-alignment stays on the left side, which is unfortunate. I realize I can switch the text-alignment using the dir attribute like so:
<input dir="rtl" />
My plan is to use JavaScript to somehow detect an RTL input language and add this attribute to all inputs and textareas. However, this seems like a bit of a hassle. Is there an easier way I'm overlooking? I don't like the idea of adding more JavaScript for this simple task.
If the whole page is written in hebrew or arabic, you should add the dir attribute on the html element, along with a lang="he" / lang="ar" attribute (the latter is for VoiceOver not reading hebrew/arabic believing it's english. The alphabet and pronunciation are quite different :) ).
If only parts of the page are written in hebrew, then each element containing hebrew text should've these attributes (or its parent) and the other parts in english should've dir="ltr" lang="en" attributes so that no text is left without the appropriate lang and dir attributes. It's faster to add them on a single parent than on each individual HTML elements and if a parent has 5 nodes in english and 1 in hebrew, it only needs 2 attributes: 1 on parent for lang="en" dir="ltr", the other on the child element containing hebrew.
For styling problems caused by rtl writing, you can use one of these attributes as a giant switch for each CSS property like float that uses left or right values (and properties like right, border-right, margin-right, margin: t r b l;; please see the second part of one of my first answers here on UTF-8 and CSS. Note: iOS has no problem with advanced CSS selectors that were only dreams when we had to support IE6 ;) )
Related
I am working on a series of computer manuals which are supplied as DITA code (a dialect of XML) and then translated before being rendered into PDFs. The PDF renderer automatically selects the RTL text direction and right-aligns the text in Hebrew and Arabic. However, there are some topics within the file that aren't translated, and it right-aligns them too. I have tried putting dir="ltr" within the <topic> tag, but that had no effect. I tried adding align="left" to the <topic> tag, then to the <p> (paragraph) clauses within it, but according to the DITA standard these tags don't recognise the align attribute, which is only available for various table elements. Is there a way to override the default (in this case, right-margin) alignment for a paragraph or larger block within a DITA file? Note that it is not feasible to rewrite the text using tables: we have to stick to the DITA structure supplied by the client.
What PDF renderer are you using? If the DITA Open Toolkit, 1) What version, and 2) Are you using a custom plug-in?
You might find more help on the dita-users list which is hosted on groups.io.
[Stackoverflow disallows the word help in the title. Hence the h3lp]
We are in the proces of moving our code from Orbeon 3.9 to Orbeon 4.x. One of the many things that changed is the behavior for display of xforms:alert and xforms:help. Example code:
<xforms:input ref="#code">
<xforms:alert ref="$resources/required-field"/>
<xforms:help ref="$helptext"/>
</xforms:input>
In Orbeon 3.9 the alert is displayed as a red img with a white exclamation mark that has the text as tooltip, only if the binding fails. The help is displayed as a blue-ish image with a question that activated a tiny pseudo window containing the (potentially large) help text.
In Orbeon 4.7 the alert text is displayed as-is, no image and no condition based on binding. This interferes with a carefully designed interface as it takes up a lot more space. The help text is not displayed at all because .xforms-help has display: none;. Overriding that doesn't work because the text would then just be displayed inline.
I could not find documentation for these changes. Does anyone know the rationale and how to make "alert" and "help" useful yet again?
There are two changes with Orbeon Forms 4.x which might be relevant to this:
The HTML layout of elements has changed a bit. This means existing CSS might have to be adapted. You can check this by comparing the HTML produced by 3.9 vs. 4.x for a given page. With 4.x, all form elements, for example, are wrapped within a <span> or <div> element.
Form Runner uses Twitter Bootstrap as a CSS library. But the Bootstrap CSS files are also included for non-Form Runner pages.
This said, "red icon" alerts should still work, see for example the good old Espresso Order or Bookcast demos.
If you see alerts inline and unconditionally, it means that somehow the proper CSS doesn't apply, either because of the HTML layout change mentioned above, or because some CSS files are missing.
Look at this post : http://blog.orbeon.com/2014/01/improving-how-we-show-help-messages.html
and this : http://discuss.orbeon.com/how-to-use-the-quot-new-quot-xforms-help-in-4-5-td4658348.html
julien
In my rails application, people are supposed to submit "posts." However, in the default scaffolding, there are some problems in the text input: not allowed HTML code, changing the line doesn't work, etc. From what I've learned, I need to use a markdown-markup language to solve this issue. Is there a guide for me to follow to apply such language to solve my problem?
UPDATE: Here are my problems.
1) Every sentence is combined into one line even if I put a line space.
first line
second line
becomes
first line second line
2) I can't make text bold, italicized, or hyperlink. Like in stackoverflow, user should easily put <b> and make bold text, ** to make italicized, etc. And URL address should automatically be translated to href link.
To do these, I thought I had to use markdown library. I could be mistaken, so I needed someone to guide me through. Railscasts on Markdown
Well, yes, new lines in HTML have no meaning. You need to replace line breaks with <br> to preserve them in HTML. To automatically highlight links, you need to look for links in the text and wrap them in appropriate <a> tags. Finally, if you're not filtering HTML tags, they should still be in there. It all depends on what you're doing. Markdown is something entirely different, a special markup language that enables you to do the above while being easier to write than HTML. It depends on what you want to use.
I have a micropost feature and was testing the way it formats text that has been posted when displaying back to the user.
I pasted the following text like this:
and this was displayed back to me:
I'm using "simple_format h(content)". When I remove the helper the text is displayed with out a new line from the word "In". It displays as one big paragraph so I assume the helper is working but for some reason my double new lines are being ignored.
Any idea what is going on? Am I missing something?
By seeing it back, do you mean inside a textarea, or on the page? If it's on the page, all whitespace is compressed to one space each. If it's the latter, simply use the css rule:
white-space:pre;
On the proper selector.
However, if it is in a textarea (which preserves whitespace by default), there must be something stripping the extra space when you save it into the database. You might want to debug down your stack in the model & controller, to see where this might be happening. I have to admit i haven't used the the simple_format method.
Thanks to chrome developer tools as per usual. I realised that each text separated by 2 new lines were wrapped with p tags so I just added a bottom margin of 5px using css to p. Works perfectly.
When I enter a text with line-breaks and long sentences, I don't want to see a wrapped or without line-breaks version. What is the CSS style to accomplish this? So far I tried white-space property but none gives the result I want.
You probably want the wrap attribute of the textarea tag. Have a look at this page: http://www.tizag.com/htmlT/htmltextarea.php
I'm not 100% sure what end result you want, but if you look at the options and explanations given via that link, you should be able to choose the one that fits your needs.
As #erik said, the way to do this is to use the wrap attribute on the tag itself, i.e.:
<textarea wrap="off"></textarea>
I just wanted to note, in case you're finicky about HTML validation, that the wrap property of textarea isn't part of any HTML standard.
Unfortunately, this is the only way to do this since the white-space CSS property, as you've discovered, doesn't work quite like you would expect when it comes to <textarea> elements.
Via Sitepoint:
Internet Explorer [...] The values normal and pre behave like pre-wrap on textarea elements. The value nowrap behaves like pre-line on textarea elements.
Firefox versions up to and including 3.0 don’t support the values pre-line and pre-wrap (although -moz-pre-wrap is similar to the latter). The values normal, nowrap, and pre behave like pre-wrap on textarea elements.
Opera 9.2 and prior versions don’t support the value pre-line. The values normal and pre behave like pre-wrap on textarea elements. The value nowrap behaves like pre-line on textarea elements.