From 991822bc8ead319d0bf7196196ce2a5f4a197f75 Mon Sep 17 00:00:00 2001 From: r12a Date: Fri, 23 Oct 2015 16:07:50 +0100 Subject: [PATCH] changed 'more' links to point to TR draft instead of ed draft this will be needed for when the techniques index is generated --- index.html | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/index.html b/index.html index b16b397..0fdcc9f 100644 --- a/index.html +++ b/index.html @@ -281,7 +281,7 @@
How to's

Designing character escapes

-

​Specifications should provide a mechanism for escaping characters, particularly those which are invisible or ambiguous. more

+

​Specifications should provide a mechanism for escaping characters, particularly those which are invisible or ambiguous. more

It is generally recommended that character escapes be provided so that difficult to enter or edit sequences can be introduced using a plain text editor. Escape sequences are particularly useful for invisible or ambiguous Unicode characters, including zero-width spaces, soft-hyphens, various bidi controls, mongolian vowel separators, etc.

For advice on use of escapes in markup, but which is mostly generalisable to other formats, see Using character escapes in markup and CSS.

​Specifications SHOULD NOT invent a new escaping mechanism if an appropriate one already exists. more

@@ -507,10 +507,10 @@

Language

Establishing the language of a resource as a whole

Here we are talking about a whole HTML page, an XML document, a Json file, a WebVTT script, etc.

-

​It must be possible to indicate the default text-processing language for the resource as a whole. more

+

​It must be possible to indicate the default text-processing language for the resource as a whole. more

It saves trouble to identify the language, or at least the default language, of the resource as a whole in one place. For example, in an HTML file, this is done by setting the lang attribute on the html element.

Content within the resource should inherit the language so set, unless it is specifically overridden.

-

​Consider whether it is necessary to have separate declarations for the text-processing language and metadata about the expected linguistic characteristics of the intended consumer. more

+

​Consider whether it is necessary to have separate declarations for the text-processing language and metadata about the expected linguistic characteristics of the intended consumer. more

The text-processing language is the language that is relevant for processing the content when it comes to spell-checking, styling, voice production, etc. For such operations, only one language should be identified at a time for a given range of content.

Metadata about the the intended linguistic characteristics of the consumer describes the intended users of the resource as a whole, rather than specific ranges of content. For example, a blog page for an Indian technical community may contain equal numbers of posts in English and an Hindi. It may be useful to express that, as a whole, this resource contains content in both those languages (without specifying which bits of content are in which language).

@@ -520,7 +520,7 @@

Links

How to's
@@ -531,8 +531,8 @@
How to's

Establishing the language of blocks, paragraphs, or similar chunks of content

The word block is used here to refer to a structural component within the resource as a whole that groups content together and separates it from adjacent content such that the boundaries between one block and another are equivalent to paragraph or section boundaries in text. For example, this could refer to a block or paragraph in XML or HTML, an object declaration in Json, a cue in WebVTT, etc. Contrast this with inline content, which describes a range within a paragraph, sentence, etc.

-

​By default, blocks of content should inherit the text-processing language set for the resource as a whole. more

-

​It should be possible to indicate a change in language for blocks of content where the language changes. more

+

​By default, blocks of content should inherit the text-processing language set for the resource as a whole. more

+

​It should be possible to indicate a change in language for blocks of content where the language changes. more

Links

@@ -540,7 +540,7 @@

Links

How to's
@@ -551,7 +551,7 @@
How to's

Establishing the language of inline content spans

Here we refer to content that switches to a different language in the middle of a paragraph or string.

-

​It should be possible to indicate language for spans of inline text where the language changes. more

+

​It should be possible to indicate language for spans of inline text where the language changes. more

Where a switch in language can affect operations on the content, such as spell-checking, rendering, styling, voice production, translation, information retrieval, and so forth, it is necessary to indicate the range of text affected and identify the language of that content.

@@ -560,7 +560,7 @@

Links

How to's
@@ -570,7 +570,7 @@
How to's

Defining language values

-

​Where language attributes already exist and are appropriate, do not create a new one.more

+

​Where language attributes already exist and are appropriate, do not create a new one.more

For example, XML provides xml:lang which can be used in all XML formats to identify the text-processing language for a range of text.

@@ -586,7 +586,7 @@

Links

How to's
@@ -604,7 +604,7 @@

Links

How to's
@@ -634,7 +634,7 @@

Setting the bidi direction for the resource as a whole

Establishing the bidi direction for blocks, paragraphs, or similar chunks of content

​The content author must be able to indicate parts of the text where the base direction changes. This should be achieved using attributes or metadata at a block level, and not rely on Unicode control characters.

​It must be possible to also set the direction for content fragments to auto. This means that the base direction will be determined by examining the content itself.

-

​A typical approach here would be to set the direction based on the first strong directional character outside of any markup, but this is not the only possible method. The algorithm used to determine directionality when direction is set to auto should match that expected by the receiver. more

+

​A typical approach here would be to set the direction based on the first strong directional character outside of any markup, but this is not the only possible method. The algorithm used to determine directionality when direction is set to auto should match that expected by the receiver. more

The first-strong algorithm looks for the first character in the paragraph with a strong directional property according to the Unicode definitions. It then sets the base direction of the paragraph according to the direction of that character.

Note that the first-strong algorithm may incorrectly guess the direction of the paragraph when the first character is not typical of the rest of the paragraph, such as when a RTL paragraph or line starts with a LTR brand name or technical term.

For additional information about algorithms for detecting direction, see Estimation algorithms in the document where this was discussed with reference to HTML.

@@ -647,12 +647,12 @@

Establishing the bidi direction for blocks, paragraphs, or similar chunks of

Establishing the bidi direction for spans of inline content

​It must be possible to indicate spans of inline text where the base direction changes. If markup is available, this is the preferred method. Otherwise your specification must require that Unicode control characters are recognized by the receiving application, and correctly implemented.

-

​It must be possible to also set the direction for a span to auto. This means that the base direction will be determined by examining the content itself. A typical approach here would be to set the direction based on the first strong directional character outside of any markup. more

+

​It must be possible to also set the direction for a span to auto. This means that the base direction will be determined by examining the content itself. A typical approach here would be to set the direction based on the first strong directional character outside of any markup. more

The first-strong algorithm looks for the first character in the paragraph with a strong directional property according to the Unicode definitions. It then sets the base direction of the paragraph according to the direction of that character.

Note that the first-strong algorithm may incorrectly guess the direction of the paragraph when the first character is not typical of the rest of the paragraph, such as when a RTL paragraph or line starts with a LTR brand name or technical term.

For additional information about algorithms for detecting direction, see Estimation algorithms in the document where this was discussed with reference to HTML.

​If users use Unicode bidirectional control characters, the RLI/LRI/FSI with PDI characters must be supported by the application and recommended (rather than RLE/LRE with PDF) by the spec.

-

​Use of RLM/LRM should be appropriate, and expectations of what those controls can and cannot do should be clear in the spec. more

+

​Use of RLM/LRM should be appropriate, and expectations of what those controls can and cannot do should be clear in the spec. more

The Unicode bidirectional control characters U+200F RIGHT-TO-LEFT MARK and U+200E LEFT-TO-RIGHT MARK are not sufficient on their own to manage bidirectional text. They cannot produce a different base direction for embedded text. For that you need to be able to indicate the start and end of the range of the embedded text.  This is best done by markup, if available, or failing that using the other Unicode bidirectional controls mentioned just above.

​Provide dedicated attributes for control of base direction and bidirectional overrides; do not rely on the user applying style properties to arbitrary markup to achieve bidi control.

​Allow bidi attributes on all inline elements in markup that contain text.

​Provide attributes that allow the user to (a) create an embedded base direction or (b) override the bidirectional algorithm altogether; the attribute should allow the user to set the direction to LTR or RTL in either of these two scenarios.

@@ -666,7 +666,7 @@

Enabling vertical text display

Setting box positioning coordinates when text direction varies

-

​Box positioning coordinates must take into account whether the text is horizontal or vertical. more

+

​Box positioning coordinates must take into account whether the text is horizontal or vertical. more

It is typical, when localizing a user interface or web page, to create mirror-images for the RTL and LTR versions. For example, it is likely that a box that appears near the left side of a window containing English content would appear near the right side of the window if the content is Arabic or Hebrew. It should preferably automatic for this to change, based on the base direction of the current context, unless there is a strong reason for using absolute geometry. One way to achieve this is to use keywords such as start and end, rather than left and right, to indicate position.

@@ -683,7 +683,7 @@

Miscellaneous

​Line heights must allow for characters that are taller than English.

​Box sizes must allow for text expansion in translation.

​Ruby text alongside base text should be supported for CJK text.

-

​Line wrapping should take into account the special rules needed for non-Latin scripts. more

+

​Line wrapping should take into account the special rules needed for non-Latin scripts. more

Various non-Latin writing systems don't simply wrap text on inter-word spaces. They have additional rules that must be respected. For example

  • Chinese, Japanese and Korean wrap after characters, but don't put certain characters at the start/end of a line.
    • @@ -692,7 +692,7 @@

    Miscellaneous

  • Indic and other complex scripts break at orthographic syllable boundaries, which are often two or more grapheme clusters.

See the CSS Text Level 3 specification for additional background. (This tutorial provides additional examples, if needed.)

-

​Avoid specifying presentational tags, such as b for bold, and i for italic. more

+

​Avoid specifying presentational tags, such as b for bold, and i for italic. more

It is best to avoid presentational markup b, i or u, since it isn't interoperable across writing systems and furthermore may cause unnecessary problems for localisation. In addition, some scripts have native approaches to things such as emphasis, that do not involve, and can be very different from, bolding, italicisation, etc.

In the HTML case, there was a legacy issue, but unless there is one for your specification, the recommendation is that styling be used instead to determine the presentation of the text, and that any markup or tagging should allow for general semantic approaches.

For an explanation of the issues surrounding b and i tags, see Using <b> and <i> elements.

@@ -725,7 +725,7 @@

Plain text support

Miscellaneous

​Avoid natural language text in elements that only allow for plain text and in attribute values.

-

​Provide a span-like element that can be used for any text content to apply information needed for internationalization. more

+

​Provide a span-like element that can be used for any text content to apply information needed for internationalization. more

Internationalization information may include a change of language, bidirectional text behaviour changes, translate flags, etc.