W3C home > Mailing lists > Public > www-international@w3.org > January to March 2014

Re: Two new encoding related articles for review

From: Richard Ishida <ishida@w3.org>
Date: Mon, 24 Mar 2014 17:33:14 +0000
Message-ID: <53306C5A.7030504@w3.org>
To: www-international@w3.org
On 20/03/2014 19:08, Gunnar Bittersmann wrote:
> Richard Ishida scripsit (2014-03-17 17:29+01:00):
>
>>> http://www.w3.org/International/questions/qa-choosing-encodings-new
>>>
>>> However, I don’t think that the keywords should be marked-up as <strong
>>> class="kw">
>>>
>>> Stick with code elements, or use span or b. Or for the character
>>> encodings, no markup at all, as before.
>>>
>>> (Don’t replace all occurences of ‘strong’ with ‘code’, there’s a
>>> ‘strongly’ in the text.)
>>
>> The idea was to make them stand out visually. I replaced strong with b.
>
> You were using ‘ASCII’, “UTF-8’, ‘UTF-16’ and ‘UTF-32’ with no special
> visual emphasis throughout the upper three quarters of the article. Why
> here?
>
> To my taste, it does not improve the readability of the text, quite the
> contrary.
>
> If you really want to make them stand out visually: There’s still
> ‘UTF-8’ and ‘ISO-8859-8-i’ without that markup in one of these
> paragraphs. And in other articles, such keywords are marked-up as <code
> class="kw"> and set in normal font weight. Here it’s <b class="kw">,
> bold font, inconsistently.
>
> My proposal is: Display encoding names as normal text, no markup.
>
> ‘replacement’ and ‘x-user-defined’ are good candidates for that keyword
> markup, though. But not in bold, but in normal monospaced font, i.e. use
> the code element.

I think you are coming at this from a different angle than I intended. 
This styling is not intended to be systematically applied per the style 
sheet. It's adhoc styling, intended to help readers quickly zoom in on 
references to the encodings referred to in that section that are 
discouraged. It's specific to that section, and the UTF-8 and 
ISO-8859-8-i encodings are not discouraged, so are not highlighted.


>
>
>>> And shouldn’t this link to
>>> http://www.w3.org/International/questions/qa-visual-vs-logical#term_visualordering
>>>
>>>
>>> given that ‘logically ordered’ links to
>>> http://www.w3.org/International/questions/qa-visual-vs-logical#term_logicalordering
>>>
>>>
>>> ?
>> No. That's what i wanted.
>
> To me it’s strange that ‘logically ordered’ (marked-up as "termref")
> points to the description of that term while ‘visual encoding’ (also
> marked-up as "termref") does not accordingly, but points to the whole
> article instead.

The link refers to 'visual encoding', rather than 'visually ordered', 
which is the term defined on the target page. But you're right that this 
shouldn't be a termref link.

>
> I think the best phrase to use as link title for the whole article would
> be ‘should also be avoided’.
>
> The anchor links might be out of the scope of this article; most of the
> target audience of qa-choosing-encodings don’t have to deal with RTL
> scripts, and Hebrew in particular. And those who do will read the entire
> article qa-visual-vs-logical anyway.
>
> My proposal is: Link to that article just once, without fragment
> identifier:
>
> … (Hebrew visual encoding) <a
> href="/International/questions/qa-visual-vs-logical">should also be
> avoided</a>, in favour of an encoding that works with logically ordered
> text …

'should be avoided' refers to the encoding ISO-8859-8, so if you put a 
link on it it would need to point to 
http://www.w3.org/International/questions/qa-visual-vs-logical#characterencodings 
specifically.

I changed the text to "(Hebrew encoding for visually ordered text)" with 
a termref link.

> »»
> that maps every octet to the Unicode code point
> ««
>
> This is the only time when the term ‘octet’ is used in this article.
> Would the term be clear to the reader? Or would it be better to use
> ‘byte’ in this context (even though that might be less accurate)?

I think octet is ok.

RI
Received on Monday, 24 March 2014 17:33:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:36 UTC