First of all sorry for this perhaps silly question. But I'm trying to figure out if the <dir="rtl"> attribute really is mandatory when displaying arabic characaters on a web page.
I've searched for a while now on this subject but I'm still puzzled. The W3C website states: "If a document contains right-to-left characters, and if the user agent displays these characters, the user agent must use the bidirectional algorithm." Source: https://www.w3.org/TR/html4/struct/dirlang.html
As far as I understand the above text this means that you will have to use <dir="rtl"> attribute but I can't find out why exactly.
The reason I'd like to know is that we have to create a 'somewhat' arabic version of a page without spending too much time on aligning and mirroring the whole website.
Does somebody know why the <dir="rtl"> attribute is mandatory? Or why it maybe why it is not mandatory? The more I read about it the more it starts messing with my head and I have a hard time finding a clear answer.
Kind regards,
Jan-Willem
This is mandatory because; 1. Its makes bots and users know how what language your page uses. 2. Its would display the text according to how that language is expected to be, rtl is mearnt for arabic and/or hebrews.
Related
I'm trying to store some text containing html tags into properties, which doesn't work. I created a form for a property with the data type 'text' and a template. Saving the form writes the text into the template, but it can't get displayed, as it contains illegal characters, as I guess.
What I'm trying to do:
I need a form to enter data, containing html tags and special
characters
I'd like to be able to use a query to find all those pages
and show that text using a template I provide to the ask query.
I also tried to use the free text option, but then I can't retrieve it using the ask query.
What would be the best, or at least a working solution to this?
Thanks a lot
storing text with html tags is a bit tricky in SemanticMediaWiki
The reason is the invention of the StripMarkers UNIQ/QINU by the MediaWiki developers.
When parsing the content of page with html tags in it the parsing is sort of "postponed". This technical detail unfortunately makes it hard for extension developers like the SMW developers to solve the issue of handling such content. Also it makes it hard for lay people to follow the discussion on how to solve the problem
Here are two examples of SMW Issues that are marked as "closed". This state of affairs means that by following the configuration hints in the issue your problem should be solved. If not please ask a question on the SMW issue list or even initiate the reopening of the issues.
https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/794
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3707
On my wiki we ran into this and resolved it by replacing special characters (we had issues with [ ] =, but the same problem happens with to < > tags too) with alternate unicode characters using the regex extension and a template before setting the property with {{#set:}}. If you want to display the formatted text on the wiki directly then call that parameter separately without replacing the unicode characters.
When you want to display the property, you can then run the reverse replacement with regex before displaying your now intact code (using the template result format to allow you to perform the operation on the output of the query).
To switch to special characters you can create this template
{{#regex:{{#regex:{{#regex:{{#regex:{{#regex:{{{1|}}}|/=/|꞊}}|/\[/|［}}|/\]/|］}}|/>/|≽}}|/</|≼}}
And to switch back you can use this as a template
{{#regex:{{#regex:{{#regex:{{#regex:{{#regex:{{{1|}}}|/꞊/|=}}|/［/|[}}|/］/|]}}|/≽/|>}}|/≼/|<}}
I'm creating a very simple form that has a text area. The text area takes in a formatted block of names separated by newlines. To make the application slightly more useable, it would be nice if I could include a placeholder example that had multiple lines of text. Unfortunately, that doesn't seem to be possible with the HTML5 specification. Does anybody know why?
<placeholder> is like <blockquote> to me. It has a specific niche.
In the case of the <placeholder> attribute, it's mainly used in one-line form fields; not text areas.
How often do you use a carriage return in a one-line form field? Never.
The <placeholder> attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. The attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.
Since HTML5 is still fresh, new, and continues to be optimized and tweaked in various browsers; who knows what crazy things would happen cross browser-wise if the <placeholder> attribute didn't have such strict guidelines set up?
The web seems to be moving in the direction to help designers/developers type less code, and make less mistakes.
I've seen a few posts (by people like Paul Irish and Jeffrey Way) talking about omitting things like closing tags, and many standard elements have been modified in HTML5 to be shorter/easier (e.g.<!doctype html>). Also, what used to be traditional attributes required to make a webpage function well can now be easily thrown out all together. The web is getting simpler, and more complex at the same time.
All in all though, if you're wanting something to fix the dilemma (that you are seemingly suffering from by the tone of your question), then just use the <title> attribute instead. Refer to the selected answer in the question located at the following link:
Can you have multiline HTML5 placeholder text in a <textarea>?
I have a website with Dutch text which I want to translate to English. Is there a fast way of doing this with keeping the HTML tags(<strong>,<span>) in tact. I know I can just copy the parsed TEXT into a translator but this will remove the formatting.
I also know that at the end I have to go trough the text manually to fix some minor spelling and grammar.
Online translators are good to turn foreign text into something that can be understood, but they are useless for producing quality translations. Even if you fix obvious problems at the end, you will get an amateurish word-by-word translation. If you want your visitors to take you seriously, you should translate from scratch.
If you want to preserve the HTML formatting at the same time as translating, you will have to work directly with the HTML source and update the text yourself without touching the formatting.
You may be able to use an XML editor like XmlSpy that will let you edit text nodes directly without touching the tagging, but this requires that the HTML is actually XHTML. You may still need to translate some attributes (such as title and alt attributes).
Is a virtual traslate a good option for you? Because if you paste google translato script into your page source, it will translate your text on the site, and the formating will stay there too. http://translate.google.com/translate_tools
I've found the outlined versions, but I want the solid up and down triangles.
Does anyone know these entities?
All named HTML entities are specified in chapter 24 of the HTML standard. The only thing missing from the page are rendered entities, but you can easily create your own copy with the additional information by applying a simple regexp:
s/<!ENTITY (\S+)/<!ENTITY \1 &\1;/
Not all entities are named. For many, you need to specify the Unicode code page, either in decimal (▲ ▲, ▼ ▼) or hex (▲ ▲, ▼ ▼).
A little but late, but you can use ▾ ▾, and ▴ ▴, to make both the up and down filled in triangles. I was looking for it myself and the alt codes didn't help so I decided to share this. This same thing works for both left and right as well.
I don't know if I've ever seen what you're looking for. Maybe a better way of doing it would be to create the arrows in Photoshop on a transparent background (.gif or .png format), and then load up the images.
Check that, you can do it through alt characters.
http://www.tedmontgomery.com/tutorial/ALTchrc.html
▼ ▲
using the alt characaters on your computer keyboard is a big no no if you are working on a web page for many reasons. #1. encoding of the website, encoding of the database driving the website if any, the codepage of the computer view the website, the codepage your own pc's keyboard is set to.. all that are mostly factors you can not control. So some people will see wonky weird letter combos or sqiggle characters instead of what you intend. For webpages use the html codes for those characters when ever you can. or at least entity encode and make sure you have your code page defined in your html header of your site.. that way people will see what you intend them to.
now if you are doing this in word for a document that will be viewed in your own country you are probably safe. But for online things (site coding or data entry) you should avoid this like the plague.
Let's face it: writing proper, standards compliant HTML is quite difficult to do. Writing semantic HTML is even more so, but I don't think it's possible for a computer to figure that out.
So my question to you is what would the "ideal" feedback for a user who entered HTML be? Would it be a W3C validator style list of errors and corresponding line numbers and columns? Would it be a annotated code display of highlighted lines, explanations of the errors, and possible fixes? A spell-check style mode where you handle each error separately? Would it be not giving them any error information at all? Also, what types of errors are a good idea to tell users? (Some broad classes of errors include parsing errors, nesting errors (i.e. putting a div in a b tag) and well-formedness errors.)
Scottm: Good point; I've never liked the W3C way of listing all the errors either. However, there is still the question of then letting the user edit the offending HTML appropriately.
onebyone: Ok, so looking at some screenshots it looks like HTML Validator has a W3C error list, but combined with the ability to go straight to the relevant source segment and expanded error information, as well as the fact that you don't have to go scrolly to jump from one section to another. Looks pretty good, but is it usable by the average Joe?
Edit 1: As a clarification, this is with regards to the interface, not necessarily the underlying implementation. However, interface needs to be feasible with plain HTML and JavaScript (double usability points if it just needs HTML, but I think you're going to get stuck with W3C in that case).
The output from the Firefox "HTML validator" add-on is pretty good. It shows you the source in a big window, and a list of errors in a small window (smallness doesn't matter, since you generally only care about the first one, since you're aiming for a total of none). Click an error to highlight, and an expanded explanation is shown in a second small window, while the offending part of the code is highlighted in the big window.
The add-on doesn't include a text editor, though, so it's not a full solution to your problem. It uses both an SGML-based validator and HTML Tidy, though, and I think for local files you can get it to make the corrections suggested by Tidy.
I always think syntax highlighting is great. In HTML this would be very useful too, as tags can be easily distinguished by the developer when he/she can see them appropraitely coloured.
Personally I don't like the W3C way of giving you a big boring list of problems. Visual aids in the code itself are much better.