14581 2011-10-27 22:54:30 +0000 Multiline text on canvas 2011-11-02 20:53:51 +0000 1 1 1 Unclassified HTML WG HTML Canvas 2D Context unspecified Other other RESOLVED NEEDSINFO http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian ian jonas mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 59109 0 contributor 2011-10-27 22:54:30 +0000 Specification: http://www.w3.org/TR/2dcontext/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: filing a separate feature request as requested in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14562 --- Please add support for multiline text. more people than you think want to use graphics-manipulable text on their canvas. As the graphics contact for canvas2D is expressly not a text element, please undo the decision to treat text rasterised onto it the same as text intended for page placing, and treat whitespace characters such as spaces and newlines as distinct instructions. This will still not break work already done by people so far because they will have implemented their workarounds to do exactly what a proper implementation would do anyway. In response to the comment that "if you need multiline text, you are almost certainly misusing canvas for something that is better done either using straight HTML and CSS, or at a pinch using SVG", this sounds like a comment made under an assumption about text that is generally not true, and misses an important distinction in what "text" means: there is a difference between typographical text (i.e. the text you read and understand as representing a language construct), and graphics based on text (i.e. using text as a pixel stencil, using it for artistic purposes). I wholly agree that the canvas is not for typographical text. We already have HTML+CSS and even SVG, and we don't need yet another element for rendering text for reading. But, thinking that thought through, this has as immediate consequence that using the same constraints for text on a canvas as are in place for typographical text on a webpage makes no sense. If canvas is not for typographical text as part of a webpage, why implicitly pretend it's typographical text on a webpage anyway by using those constraints? People who are used to working with rasterised text as graphics --expressly NOT as typographical text-- from applications such as Photoshop, Paint.net, The Gimp, etc. are used to the text being typeset the way they dictate it (multiple spaces being multiple spaces, newlines acting as line breaks, etc.) so that they can then manipulate the graphics context with that text firmly rasterised on it, not acting as text at all, but as pixels that can be copied, mixed, and overwritten. Not all text is language. Sometimes (and definitely in raster graphics contexts such as the 2d canvas) it's just a graphics primitive, and should just be rendered as such. Posted from: 205.250.164.138 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.187 Safari/535.1 59366 1 ian 2011-11-01 05:58:15 +0000 What is the use case? 59528 2 ian 2011-11-02 20:53:51 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 1