[HDP] Other comments from RI

These are comments I wanted to make while responding to http://www.w3.org/2002/09/wbs/40318/dprv/  They reflect my own personal views.




> 2. Support Existing Content

Strongly agree with the principle per se
Agree with the wording...

BUT... the spec should not read as if it's ok to continue with less desirable practices.  It should be very clear to the reader that support is provided for legacy documents, but you should not use broken markup, font tags, etc for new content. This should be mentioned in the text for this principle.




> 3. Degrade Gracefully

Agree with the principle per se

However, backwards compatibility should not preclude the possibility of deprecating substandard ways of doing things and developing better alternatives.

Also, we should not tie HTML to the lowest common denominator in terms of browser support. In fact, in the statement "new features should work reasonably well in older user agents that do not support the functionality" what constitutes an 'older browser'?  I'd be very reluctant to abandon hex NCRs just because Netscape 4 doesn't support them, since I personally think Netscape 4 is nowadays irrelevant, and people need to get a more up to date browser.

If we are working with the implementers so that the changes to the spec are rapidly adopted into the latest UA versions this should also help. 

Perhaps what we mean to say is that where it is possible to gracefully degrade content to work with older user agents we will make that possible. 




> 4. Do not Reinvent The Wheel

Agree with the principle per se

But, reinventing the wheel and improving things that don't work very well are different.  For example, adapting <img> so that alt text is content rather than an attribute would be a big help (among other things) for developers of Arabic and Hebrew content who need to apply directional tags to their alt text. Gratuitous duplication, on the other hand, should be avoided. I'd like to see this distinction made in the text.




> 5. Pave the Cowpaths

I think I agree with the principle per se, but feel the wording is a bit too vague to avoid future disagreements. For example, I disagree if this means allowing authors to continue using the font tag, etc. HTML5 should recognise the font tag in legacy docs, but we should try to wean authors away from using it in future. Authors are not inherently right.  Certainly don't prevent them using <br/>, though.




> 8. Priority of Constituencies

The question is, how to know what users and authors want - who speaks for them?  It's not necessarily loud voices that pop up on an open list or blog post.




> 11. Support World Languages

I agree with much of this, but the intent of "Features to represent a single web page in multiple languages are out of scope." is not clear.  Much of the world is multilingual and we should definitely allow for multiple languages and scripts to appear on the same page.  This is one of the key rationales for using Unicode.  If what is meant is that features to allow users to switch between alternate translated versions of content stored within the same page, this should be made clearer, but I think that whether that feature is in or out of scope will depend on what the users and authors want (see principle 3.2) and is not an appropriate thing to address in a principles document.

I also have a concern with "Italics is useful because it applies to many bicameral scripts". Firstly, it applies not only to bicameral scripts.  Secondly, 'italics' is one kind of *presentational* device that, if the default styles are not appropriate, should be applied using CSS.  The <i> tag does not equate to ruby markup at all - ruby markup is semantic in nature (and needs CSS for all but the most basic fallback default form of presentation). A better sentence may be "Directional markup is useful because it applies to many right to left scripts, even though content in some scripts has no need of it."




> 13. Separation of Concerns

I agree with the principle of separation of concerns, but have a significant issue with the text.

Certainly we should continue to support <b> and <i> tags, but we should encourage people to use <em> and <strong> instead.  I constantly see people misusing these tags in ways that makes localization difficult. 

Just because three presentational conventions (such as highlighting emphasis, document titles, and foreign words) in an English document may all use, say, italics, it doesn't hold that a Japanese document will use a single alternative presentation for the three.  They may use wakiten for emphasis, but corner brackets for document names, and guillemets for foreign words.  If the English author has used <i> tags everywhere (thinking about the presentational rendering he/she wants in English) rather than <em> and <span class="doctitle" or <span class="foreignword", the Japanese localizer will be unable to work easily with this document.

Think of it the other way around: Japanese authors may avoid both italicization and bolding, since their characters are too complicated to look good in small sizes with these effects - a Japanese author may favour  underline for a wide variety of uses and font tags for others (changes in text size and family can be used to distinguish text in Japanese).  If the Japanese author uses <u> tags for many different effects, it will become a problem to localize into English, where judicious application of italicisation here and bolding there (but no underlining) would look better.  All this could be avoided if semantic markup was encouraged, allowing the localizer into English to easily change the CSS and achieve whatever effect they wanted.

Allowing authors to use <b> and <i> tags is also problematic in that it blurs the idea of semantic markup in their mind with what really are presentational devices associated with Western scripts.


============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)
 
http://www.w3.org/People/Ishida/
http://www.w3.org/International/
http://people.w3.org/rishida/blog/
http://www.flickr.com/photos/ishida/

Received on Thursday, 23 August 2007 15:59:23 UTC