title: Thai line breaking: how to break Thai text effectively
body: <p><strong>Situation</strong>
  with Thai text on a client site is that we can't control where exactly particular words/sentences are going to break between the lines <em>(how web browser will handle it)</em>. Often, content appearance is indicated as incorrect by local reviewers.</p>
  
  <p><strong>Workaround</strong>
  to this is that copywriter needs to deliver Thai content with breaking <a href="http://www.fileformat.info/info/unicode/char/200b/index.htm" rel="noreferrer"><code>&amp;#8203;</code></a> and non-breaking <a href="http://www.fileformat.info/info/unicode/char/feff/index.htm" rel="noreferrer"><code>&amp;#65279;</code></a> zero-width-space chars included.</p>
  
  <p>In practice, rather than:<br />
  <code>ของเพื่อนๆ ที่ออนไลน์อยู่</code><br />
  we should use something as ugly as:<br />
  <code>ข&amp;#65279;อ&amp;#65279;ง&amp;#65279;เ&amp;#65279;พื่&amp;#65279;อ&amp;#65279;น&amp;#65279;ๆ&amp;#8203;ที่&amp;#8203;อ&amp;#65279;อ&amp;#65279;น&amp;#65279;ไ&amp;#65279;ล&amp;#65279;น์&amp;#65279;อ&amp;#65279;ยู่</code></p>
  
  <p>The above is just an example, I don't really know where exactly the breakpoints are allowed.<br />
  In fact, non-breaking zero spaces alone would do the trick either ... it's just more strict and correct to use breaking ones as well for better accuracy.</p>
  
  <p>And while it definitely is doable like this, it also is a time consuming and not very effective solution for a large site content management. Simply said, the effort put into it doesn't match the effect needed.</p>
  
  <p><strong>Research</strong>
  so far has lead to the workaround mentioned, looking for a better way how to handle this. Even <a href="http://lists.w3.org/Archives/Public/www-style/2011Feb/0126.html" rel="noreferrer">W3C doesn't have a solution yet</a> and is just discussing whether it should be part of CSS3 specification.</p>
  
  <p>Thai language utilizes spaces very rarely, mostly to distinguish between sentences etc. Therefore, common appearance of a Thai sentence is one looong string.
  Where to break such a string when more lines of text are put together is determined by particular words identification. For words identification local dictionaries are used which are most probably part of operating system or web browser, I'm not entirely sure about these.</p>
  
  <p>Apparently, the more web browsers / operating systems you check on the more results you get! Moreover, there's not much you can do about this as it's system driven and there are no "where to break Thai" settings available.</p>
  
  <p>Using <a href="http://www.quirksmode.org/oddsandends/wbr.html" rel="noreferrer"><code>&lt;wbr/&gt;</code></a>, <a href="http://www.quirksmode.org/oddsandends/wbr.html" rel="noreferrer"><code>&amp;#8203;</code></a> or <a href="http://www.quirksmode.org/oddsandends/wbr.html" rel="noreferrer"><code>&amp;shy;</code></a> to indicate where the breakpoints really are won't prevent web browser thinking <em>(even though wrong)</em> that some breaks are also possible in places, where you haven't defined them e.g. in the middle of a word which might be grammatically incorrect.</p>
  
  <p>If such a word is placed at the end of a line <em>(depends on screen resolution, copy length, CSS rules defined)</em> and the browser applies his wrong line breaking rule on it then you would end up with a Thai line breaking issue, no matter that you have defined another breakpoints before, after or somewhere else in the word - browser will always use a breakpoint that he thinks is closest to EOL, not just the ones you have gently suggested by inserting one of the mentioned chars in your markup.</p>
  
  <p>That's why you actually need to focus on where not to break your text <em>(non-breaking zero-width-space)</em>, not where it's allowed. And that's what lead us back to the ugly and long markup example in the "Workaround" section above. That way a line break can strictly only occur where you have allowed it to be, but it's messy.</p>
  
  <p><strong>Any other solution</strong>
  how to handle this more effectively would be appreciated ... and who knows, it might even help W3C in their implementation?</p>
  
  <p>THANK YOU!</p>