Re: [whatwg] several messages about the HTML syntax
Dnia 03-03-2008, Pn o godzinie 20:18 +, David Gerard pisze: 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 ?! Admittedly, we cannot, at least not in Firefox. Hm. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 19:51 +, Philip Taylor pisze: Are there cases where div ...a href=... style=display:block; width:100%; height:100% ... /a/div is not adequate for making block links? It does not make the anchor a block element, it is still a text element, although with block display. It cannot contain flow content. button type=submit link=javascript:event.preventDefault() The URI is semantically incorrect because event is undefined. Chris
[whatwg] HTMLDocument hasFocus - should it be a function?
I started implementing the hasFocus attribute in WebKit, but then I realized that IE and Firefox 3 both implement it as a function. Should the spec change to match the existing implementations? Thanks, Adele
Re: [whatwg] Usemap and ismap for canvas tag
Greg, I remember seeing the quote here: 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. at some point in time and thinking to myself that it was basically inaccurate. I realize it is probably not you who wrote this delightful aphorism of guidance for the rest of us, so it is not with you that I would raise objection. For me, SVG does not at all focus on pre-computed image documents, but rather it is because of its dynamic qualities that I use it. It is more complex than canvas, that is for sure. I think in terms of speed, though, it all depends on what you are doing. Try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap through your own JavaScript on a canvas image -- then let's talk benchmarks. [references available upon request] But certainly and absolutely I would have never shown SVG more than a passing glance if it had been focused on pre-computed image documents -- how boring! VML was perfectly interactive and canvas-like for most mundane purposes, it just didn't have bitblits. If MS had had the foresight to put bitblits in VML we'd all be using Silverlight now and Microsoft would buy Google. /kidding I think the aphoristic quote may have propagated from the relatively confined arena of WHATWG to the more noticeable archives of the W3C (am not sure about this) but it might be nice for whoever runs the canvas boat to steer the comparison a little more precisely. regards, David - Original Message - From: Greg Houston [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 03, 2008 11:40 PM Subject: 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
David, I really didn't mean to shift the emphasis to SVG at all. I don't think anyone is going to try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap [via] JavaScript on a canvas image. All I am doing here is making simple pie charts, and I would like those pie charts to have simple hot spots, nothing fancy. With hot spots these simple canvas graphics then have very basic interactivity such as links and tooltips without increasing the overhead of the canvas element. Also, implementing this in the browsers should be trivial since the usemap and ismap functionality already exists for the img tag. This is just about very basic functionality and is aimed to benefit simple-minded web developers like myself who are not necessarily trying to perform graphic rocket science. canvas id=myChart width=200 height=200 usemap=#myMap/canvas Greg On Tue, Mar 4, 2008 at 9:47 PM, ddailey [EMAIL PROTECTED] wrote: Greg, I remember seeing the quote here: 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. at some point in time and thinking to myself that it was basically inaccurate. I realize it is probably not you who wrote this delightful aphorism of guidance for the rest of us, so it is not with you that I would raise objection. For me, SVG does not at all focus on pre-computed image documents, but rather it is because of its dynamic qualities that I use it. It is more complex than canvas, that is for sure. I think in terms of speed, though, it all depends on what you are doing. Try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap through your own JavaScript on a canvas image -- then let's talk benchmarks. [references available upon request] But certainly and absolutely I would have never shown SVG more than a passing glance if it had been focused on pre-computed image documents -- how boring! VML was perfectly interactive and canvas-like for most mundane purposes, it just didn't have bitblits. If MS had had the foresight to put bitblits in VML we'd all be using Silverlight now and Microsoft would buy Google. /kidding I think the aphoristic quote may have propagated from the relatively confined arena of WHATWG to the more noticeable archives of the W3C (am not sure about this) but it might be nice for whoever runs the canvas boat to steer the comparison a little more precisely. regards, David - Original Message - From: Greg Houston [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 03, 2008 11:40 PM Subject: 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] several messages about the tree construction stage of HTML parsing
Executive summary: Hoo boy did these e-mails end up with a lot of complicated changes -- a total of 38 different checkins. Some were editorial, but others were quite invasive changes. Here are the main ones: * Merged insertion modes and phases. Theoretically this didn't change anything but as I'm sure I broke many things, please let me know what I should fix. Note that I did the changes in steps, to make reviewing the changes easier. (r1308-r1313) * Make a text node before an html start tag be a parse error. (r1314) * Strip spaces between html and head tags. (r1332) * Make title not get moved to head. (r1328) * Fix the processing of /form to work like /div. (r1320) * Make listing parse like pre in terms of leading newlines. (r1330) * Make spaces in table get reparented if there's been other content that got reparented. (r1326) * Make input type=hidden in table not get reparented unless something else has been reparented. (r1331) * Make style and script in table not get reparented. (r1335) * Make select inside table get handled compatibly. (r1342) * Fix bugs with the AAA algorithm in tables. (r1343) For the full list see the diffs from r1308 to r1346. On Thu, 19 Jan 2006, Simon Pieters wrote: I did some more testing[1] on this. It seems that in Mozilla and Opera, the DOM tree for... tabletbodyformtrtdinput/td/tr/form/tbody/table ...looks like this: TABLE - TBODY - - FORM - - TR - - - TD - - - - INPUT In IE6 the DOM tree looks like this: TABLE - TBODY - - FORM - - - TR - - - - TD - - - - - INPUT Even though the FORM is not an ancestor to the INPUT in the DOM tree in Mozilla or Opera, the DOM2 HTML attributes .form and .elements work as if it was. The same holds true when form is placed as a child of TABLE, TBODY (presumably also THEAD and TFOOT), and TR. [1] http://zcorpan.1go.dk/test/html/table-form/ The problem with IE's tree is that it is incompatible with the CSS tabel model. The problem with the Mozilla and Opera tree is that the form is still in the way, but since it's not an ancestor, it doesn't really have to be there at all. Hence the HTML5 processing. On Fri, 29 Jun 2007, Henri Sivonen wrote: If the spec dealt with the html start tag token directly in the root element phase, the parse error in the main phase wouldn't need to be conditional. (Implementations that experience a perf benefit from not mutating the attributes of a node probably want to hoist the html node creation to the root element phase for perf reasons, too.) Done. On Mon, 11 Feb 2008, Philip Taylor wrote: There's also an issue with: !doctype html foo html not producing any parse error, because the html is the first start tag token (at least under my interpretation) and therefore is considered valid. Handling html specially in the root element phase seems like a reasonable way of fixing this. Fixed. On Sat, 30 Jun 2007, Henri Sivonen wrote: Under before head the case 'A start tag token whose tag name is one of: base, link, meta, script, style, title' is the same as any other start tag token. Removed. On Sun, 1 Jul 2007, Henri Sivonen wrote: In the tree construction part of the parsing algorithm, void elements that are generally supposed to be children of the head element never get popped. (Void elements that are generally supposed to be descendants of the body element are appropriately popped immediately.) Fixed. (Assuming this only affected meta, base, and link while in head, anyway.) On Sun, 1 Jul 2007, Henri Sivonen wrote: Please add a note that says that the context concept of the [R]CDATA algorithm causes title to be moved to head here. No longer applicable (title is no longer reparented). On Sun, 1 Jul 2007, Henri Sivonen wrote: In the tree construction part of the parsing algorithm, the rationale for formulating the generic [R]CDATA parsing algorithm the way it is formulated is not given. The formulation is unusual compared to the rest of the chapter, so it is reasonable to expect that there's a specific reason why it is written the way it is written. It was written the way that my mind thought about it... My practical concern is this: In my implementation the tokenizer owns the main processing loop. Therefore, the tree builder can only change its state on a per-token basis and cannot pull another token in response to processing one token. (Instead, it can set its own flags, return control to the tokenizer and wait for the tokenizer to call back into the tree builder again.) I have solved the problem as follows: cdataOrRcdataTimesToPop is initialized to 0. When the spec invokes the generic [R]CDATA parsing algorithm, instead of running it, do the following: 1. If the context node is the current node, 1a. Create an element for the token. 1b. Push the element. 1c. Set the content model flag of the tokenizer. 1d. Set
