children of option

J

j

What is permitted in the label of an option? I need to mix a right to
left language with English.

I know this is wrong:

<select style="direction: rtl">
<option value="xyz">
<div>Hebrew or Arabic</div>
<div style="text-align: left">English</div>
</option>
<option value="xyz">
<div>Hebrew or Arabic another option</div>
<div style="text-align: left">English</div>
</option>
</select>

Is there a right?

Jeff
 
J

Jukka K. Korpela

What is permitted in the label of an option?

Any text
I need to mix a right to
left language with English.

Within an option element, or in different option elements of a select
element? The former is more complicated, and this seems to be the problem.
I know this is wrong:

<select style="direction: rtl">
<option value="xyz">
<div>Hebrew or Arabic</div>
<div style="text-align: left">English</div>
</option>
<option value="xyz">
<div>Hebrew or Arabic another option</div>
<div style="text-align: left">English</div>
</option>
</select>

It's indeed wrong (invalid, and won't work), because an option element
cannot contain any elements, just test.

But what is the problem? You can mix RTL and LTR languages, e.g.

<option value="xyz">
אבג English
</option>

What happens then is that words have their inherent directionality set
by the directionality properties of characters, so e.g. the Hebrew
letters here run properly right-to-left. And Latin letters run
left-to-right. The mutual order of the two words depends on the overall
directionality, which you can set with the dir=... attribute or, less
logically and less safely, with the CSS direction property.

The default is LTR, by HTML specs, but if you have <select
style="direction: rtl">, this order is overridden that text will be
written right to left, so the first word (the Hebrew "word") will appear
on the right and the second word (the word in Latin letters) on the left.

The interesting question is what the content is really like. Its
directionality should correspond to the overall directionality of text
on the page, and it should rarely be different between options of a select.

It's really rather simple. If the content is English with some Hebrew or
Arabc words embedded in it, just let the default directionality prevail.
If it is all Hebrew, or all Arabic, or all Persian, or in some other RTL
language, with some words in Latin letters thrown in, set dir=rtl
(normally, on the <html> element).
 
J

j

Any text


Within an option element, or in different option elements of a select
element? The former is more complicated, and this seems to be the problem.


It's indeed wrong (invalid, and won't work), because an option element
cannot contain any elements, just test.

OK. That makes sense. I didn't see that at w3.org.
But what is the problem? You can mix RTL and LTR languages, e.g.

<option value="xyz">
אבג English
</option>

The problem *was* that English is looked at from a left margin, and
Hebrew is started from a right margin.

But after further review, I think it's a bit nutso to split them on a
line that way. One text-align is enough and the English is still plainly
readable.
What happens then is that words have their inherent directionality set
by the directionality properties of characters, so e.g. the Hebrew
letters here run properly right-to-left.

I didn't know that. I had found it a bit of a mystery of why it worked.
Not that I can read a word of Hebrew, but I was told it was correct.

<gripe>
I had a great deal of trouble importing unicode utf-8. Microsoft
products like Excel look for a BOM (byte order marker) which I'm told
shouldn't be needed in utf-8, only in utf-16 and utf-24. But this isn't
the first time that MS has insisted on guessing wrong (enctypes).
</gripe>


And Latin letters run
left-to-right. The mutual order of the two words depends on the overall
directionality, which you can set with the dir=... attribute or, less
logically and less safely, with the CSS direction property.

I've been setting this only in CSS. Works in IE8 which is the most
primitive browser I have. CanIuse is silent on support.
The default is LTR, by HTML specs, but if you have <select
style="direction: rtl">, this order is overridden that text will be
written right to left, so the first word (the Hebrew "word") will appear
on the right and the second word (the word in Latin letters) on the left.

The interesting question is what the content is really like. Its
directionality should correspond to the overall directionality of text
on the page, and it should rarely be different between options of a select.

As it turns, I was wrong about the options needing to be in both
alignments, which simplifies my work.
It's really rather simple. If the content is English with some Hebrew or
Arabc words embedded in it, just let the default directionality prevail.
If it is all Hebrew, or all Arabic, or all Persian, or in some other RTL
language, with some words in Latin letters thrown in, set dir=rtl
(normally, on the <html> element).

That I didn't know, that you could set on the html. I had been setting
direction only on form fields and text-align: right on everything else.
I rather stumbled on direction, which was a new concept for myself.

Thanks.

Jeff
 
J

Jukka K. Korpela

OK. That makes sense. I didn't see that at w3.org.

In HTML 4.01, for example, the rule is presented in a somewhat cryptic
way, namely in an SGML declaration:

<!ELEMENT OPTION - O (#PCDATA) -- selectable choice -->

http://www.w3.org/TR/REC-html40/interact/forms.html#edef-OPTION

HTML5 says it in more commonly understood terms:

"Content model:
Text."

http://www.w3.org/TR/html5/forms.html#the-option-element

However, if you want to know exactly what "text" means here, it gets a
bit more complicated. When you follow the link "Text", you might get
worried about the statement "must not contain control characters other
than space characters" - if you might need characters that control
directionality, like U+200E LEFT-TO-RIGHT MARK. But such a character
passes validation at http://validator.nu so apparently "control
character" is not meant to cover characters in the category Cf [Other,
Format] in Unicode, probably just Cc [Other, Control].
<option value="xyz">
אבג English
</option> [...]
What happens then is that words have their inherent directionality set
by the directionality properties of characters, so e.g. the Hebrew
letters here run properly right-to-left.

I didn't know that. I had found it a bit of a mystery of why it worked.
Not that I can read a word of Hebrew, but I was told it was correct.

Hebrew is mostly Greek to me, and that's why I use simple Hebrew
characters in my tests - like the first three letters of the Hebrew
alphabet as above. Everyone knows the aleph, right? :)
<gripe>
I had a great deal of trouble importing unicode utf-8. Microsoft
products like Excel look for a BOM (byte order marker) which I'm told
shouldn't be needed in utf-8, only in utf-16 and utf-24. But this isn't
the first time that MS has insisted on guessing wrong (enctypes).
</gripe>

It is not uncommon to see warnings about BOM, even on W3C pages. The
warnings reflect the shortcomings of very ancient browsers and partly
problems that still exist in PHP, which cannot handle BOM properly when
joining PHP files. But BOM does not cause problems to any *browser* that
you might see in the wild these days. BOM actually *helps* even in a
utf-8 encoded file by making sure that browsers will interpret it as
utf-8, even if HTTP headers are missing or wrong.
And Latin letters run

I've been setting this only in CSS.

HTML5 CR says:

"Authors are strongly encouraged to use the dir attribute to indicate
text direction rather than using CSS, since that way their documents
will continue to render correctly even in the absence of CSS (e.g. as
interpreted by search engines)."

http://www.w3.org/TR/html5/dom.html#the-dir-attribute
Works in IE8 which is the most
primitive browser I have. CanIuse is silent on support.

Well, you could use both HTML dir attribute and CSS direction property.
But you hardly need that.

CanIuse mostly deals with HTML5 novelties (in a rather broad sense), and
the dir attribute is good old HTML 4. According to
http://reference.sitepoint.com/html/core-attributes/dir
there is support in IE 5.5+, which should be enough these days.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top