[whatwg] A comment to character encoding declaration
Hi, It's a comment to the character encoding declaration section of HTML 5 spec: http://www.w3.org/html/wg/html5/#character1 During the development of CJK information processing, many text encodings is just a strict subset of another one, for example, GB2312 is a subset of GBK, GBK is a subset of GB18030. For compatibility purpose, a lot of web pages used character encoding declaration like this: meta http-equiv=Content-Type content=text/html; charset=gb2312 in their header, yet they might use characters in GBK but not in GB2312. So, I think we can suggest clients to simply treat encodings like these as their biggest superset, for instance, treat GB2312 as GB18030. BTW, browsers like Firefox seems already handles such cases well, but Safari/WebKit seems not. Regards, Jiang
Re: [whatwg] several messages about the HTML syntax
Dnia 02-03-2008, N o godzinie 23:02 +, Ian Hickson pisze: On Tue, 31 Jul 2007, Simon Pieters wrote: Aha. I didn't think of testing attributes. Safari preserves CRs in attribute values, both real and NCRs. CRLF pairs, LFCR pairs, CRs and LFs cause a single linebreak in the tooltip. In data, CRs don't cause linebreaks. For title=, IE preserves CRs in attribute values, both real and NCRs. CRLF pairs, CRs and LFs in the DOM gets rendered as a signle linebreak in the tooltip. For value=, all types of linebreaks are converted to CRLF pairs. In data, only CRs cause linebreaks and LFs are rendered as spaces. Firefox preserves CRs in attribute values, both real and NCRs. CRs are ignored and LFs are rendered as spaces in the tooltip. In data, CRs don't cause linebreaks. For title=, Opera drops LFs in attribute values, both real and NCRs, and converts CRs (both real and NCRs) to spaces. For value=, CRs and LFs are preserved as written, both real and NCRs. Personally, I think attribute values should be parsed the same way as data is parsed wrt linebreaks. I agree. I oppose. When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend: convert line feeds to spaces, use #8232; and #8233; where appropriate, use #10;, #13; where necessary (these should not be converted to spaces). Chris
Re: [whatwg] The div element
Dnia 01-03-2008, So o godzinie 19:37 -0800, Nicholas C. Zakas pisze: Reading your description makes me think that you're more displeased with the hn/ elements than you are happy with the section/ element. I've never had issues promoting headers or moving content around, and I'm not clear that section/ would help in any of these circumstances. Nested sections using different hn/ elements seem more confusing to me than just using the hn/ elements. You can paste the section text without modification and the headings will get the correct level automatically. It is a good thing. Chris
Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: I understand your reasoning for the aside/ element, perhaps this is another element that is suffering from the wrong name. Most of web developers have no idea what an aside is let alone when to use one. I know that acronym/ was removed because it confused web developers. Given that this is the same audience, the ones who couldn't figure out the difference between an acronym and an abbreviation, do you really think that aside/ will get used? Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris
Re: [whatwg] Issues concerning the base element and xml:base
Dnia 01-03-2008, So o godzinie 17:12 -0800, Maciej Stachowiak pisze: On Mar 1, 2008, at 4:20 PM, Jonas Sicking wrote: For example on a a href=..., does the user hovering the node count? If you display an absolute URI to the user at this time it should get resolved against the current base, but since this is not a load, it should get resolved again when the user clicks the link, if the base changed. I am not sure I understand you correctly but if this introduces the ability to make the user agent report a different URL than the effective target, it is going to be a sweet candy for phishers. (Newer browsers made this effect unavailable to scripts). Chris
Re: [whatwg] several messages about the HTML syntax
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages about the HTML syntax
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! (i.e.: If people can do something, they will, and this needs to be allowed for. ASCII art in tooltips hits my wrong button, but it's out there. OTOH I've never seen a tooltip in a monospaced font. User-agents treating all whitespace as spaces and reformatting as nicely as they can would be fine to me. I'm sure others will come up with real-life use cases for ridiculously long tooltips.) - d.
Re: [whatwg] Issues concerning the base element and xml:base
Krzysztof Żelechowski wrote: Dnia 01-03-2008, So o godzinie 17:12 -0800, Maciej Stachowiak pisze: On Mar 1, 2008, at 4:20 PM, Jonas Sicking wrote: For example on a a href=..., does the user hovering the node count? If you display an absolute URI to the user at this time it should get resolved against the current base, but since this is not a load, it should get resolved again when the user clicks the link, if the base changed. I am not sure I understand you correctly but if this introduces the ability to make the user agent report a different URL than the effective target, it is going to be a sweet candy for phishers. (Newer browsers made this effect unavailable to scripts). It is already very possible to make a link that appears to go to one url, but in reality goes to another. Here are three examples: a href=http://www.good.com; onclick=window.location='http://www.evil.com' a href=http://www.good.com; onmousedown=this.href='http://www.evil.com' span style=color: blue; text-decoration: underline; onclick=window.location='http://www.evil.com' go to www.good.com /span / Jonas
Re: [whatwg] several messages about the HTML syntax
David Gerard wrote: On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote: When I want to define a paragraph-style tool-tip, I am left with the following choice: either make the source code unreadable by making an excessively long line (this is also true for URI attributes but they are not expected to be readable) or make the tool-tip ugly by inserting line breaks. (It cannot be done in an portable way because the width of the tool-tip window and the fount metrics at the viewer's UI are unknown). I recommend not making paragraph-long tooltips. That's terrible user interface. But how will we read the asides on xkcd.com ?! (i.e.: If people can do something, they will, and this needs to be allowed for. ASCII art in tooltips hits my wrong button, but it's out there. OTOH I've never seen a tooltip in a monospaced font. User-agents treating all whitespace as spaces and reformatting as nicely as they can would be fine to me. I'm sure others will come up with real-life use cases for ridiculously long tooltips.) The current spec doesn't forbid paragraph-style tooltips. It just doesn't pander to them. This seems like a very good tradeoff. / Jonas
[whatwg] Usemap and ismap for canvas tag
I would like to request that the canvas element get the same usemap and ismap properties that the img element has. It seems the canvas tag was designed primarily for fairly simple dynamic data visualizations, but even so, having some basic, built-in, intuitive methods for interacting with these graphics would be nice. Beyond, the standard image map, it would also be nice if after closing a path you could add the shape created to the dom and give it an ID, though I a may be pushing it with this request. You don't necessarily need to be able to directly modify the shape itself via the dom (that might be difficult since I think the canvases are drawn flattened on one layer), but merely be able to add event listeners to that shape such as onclick and mouseover. Basically what I am proposing is not much different than an image map, but one where this virtual canvas image map can be created with canvas commands rather than having to draw the shape a second time and add it to the image map separately. ... draw shape ... ctx.closePath(areaID) vs. ... draw shape ... ctx.closePath() ... draw shape again as an image map area ... ... inject newly created area into map So merely giving the canvas element the usemap and ismap properties would be helpful, though better yet if canvas shapes/areas could be added to the dom directly. The following is an example of a canvas pie chart with a dynamically generated image map overlayed on top of it. Since the canvas element does not as of yet have a usemap property I had to use a blank transparent gif for the overlay. http://demos.greghoustondesign.com/piechart/ Also, again realizing I am pushing it, in the modern world it would probably be nice if there was an image map shape type that supported bezier curves. In the example above the circumference of each pie slice is approximated with several vertices. Cheers, Greg
Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris Call it note. It may sound crude but it's hard to mistake its meaning. Shannon
Re: [whatwg] several messages about the HTML syntax
On Sun, 2 Mar 2008 23:02:07 + (UTC), Ian Hickson wrote: On Sat, 15 Sep 2007, Henri Sivonen wrote: Currently, unquoted attributes may start with a = [as in img alt==Foobar src='404'] This means that the notion of conformance fails to catch what is most likely an error: [...] To make the notion of conformance more useful for authors (that is, to make conformance checking catch unintentional stuff), I suggest making starting an unquoted attribute value with a = a parse error. Done. On Mon, 17 Sep 2007, Øistein E. Andersen wrote: An alternative solution would be to require that unquoted attribute values not contain (single or double ASCII) quotes. Done. I really meant to say that disallowing quotation marks in unquoted attribute values would make conformance checkers able to detect the particular error pointed out by Mr Sivonen even without disallowing equals signs. (The editor may well have noticed this, but his answer does not reflect this.) Other potential authoring mistakes pointed out since support the case for disallowing quotation marks. I am still not convinced about the usefulness of disallowing equals signs, but I have not considered the issue of which characters should be allowed or not in any detail. -- Øistein E. Andersen
Re: [whatwg] several messages about handling encodings in HTML
On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote: (I've made the characters not allowed in XML also not allowed in HTML, with the exception of some of the space characters which we need to have allowed for legacy reasons.) The C1 character U+0085 NEXT LINE (NEL) is also a Unicode space character, and this one is neither disallowed nor discouraged in XML as far as I can tell. I am not sure if we really want to support this character, though; Opera, Safari and Firefox do not seem to recognise it at all, and one IE7 installation seems to treat it as a non-breakable wide space, but this may well be font-dependent. (Allowing this character could be confusing given that #x85; does not refer to U+0085, but rather to an ellipsis for compatibility with Windows-1252.) More importantly, the current draft seems to allow C0 (not only white space) controls and delete, as well as U+FDD0 to U+FDDF and the non-characters *FE and *FF when these are expressed as character references. Would it be possible to (dis)allow the same set of characters in both cases? -- Øistein E. Andersen
Re: [whatwg] Usemap and ismap for canvas tag
Wouldn't it make more sense just to use SVG? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Usemap and ismap for canvas tag
Wouldn't it make more sense just to use SVG? Dynamic interactive charts and graphs seem to fall into the gray area between what is more appropriate for canvas or SVG. canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Greg
Re: [whatwg] Usemap and ismap for canvas tag
On Tue, 04 Mar 2008 13:40:52 +0900, Greg Houston [EMAIL PROTECTED] wrote: Wouldn't it make more sense just to use SVG? ... So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. This seems to make sense to me. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Right. On the other hand, loading it with a DOM would slow it down to the point that it loses its major benefit over SVG (at least as I see it) - the fact that it is relatively lightweight, ergo faster. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
