Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Sun, 11 Mar 2007, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. find replacements for * link rev We removed rev= because it was only used correctly for one thing (rev=made) and was misused a _lot_, and the number of people using rel=author was comparable (I forget the exact numbers). * a name This was removed purely to simplify the language. * empty a elements Those are legal now. * hr size * img align * table align * table width * td align Those should all be removed anyway to improve your content/style separation, which would aid with maintenance. (I'm assuming here that you'd want to transition the document only if it was a document in active development, in which case maintenance is relevant. If maintenance is not relevant, there's no reason to transition the document.) * review whether I use any so-called predefined classes and if, whether I use them correctly, or find out how to replace them These are gone now. * review whether I am MicroformatsOK according to the latest Wiki pages HTML5 doesn't require this any more than HTML4 now. * review whether my img elements are really some piece of text with some alternate graphical representation This you should do anyway for accessibility reasons. * review whether my images are all the exact size given in the height and width attributes This you should do anyway to obtain quality results. and so on, whereas switching to XHTML would simply be a matter of running HTML Tidy on all the files and lowercasing the selectors in the style sheets? It's a lot of work if I just want to add my favourite HTML5 feature to the page. Well, that's what you get for using a Transitional markup language without intending to transition. :-) Note that moving to XHTML 1.1 would require many of the same changes, since it also omits the Transitional features. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Archives
On Wed, 11 Apr 2007, Tyler Keating wrote: I apologize if I've missed this in the specification or mailing archives, but I have a suggestion related to standardizing web archives in HTML5. Currently, I know that Firefox uses Mozilla Archive Format (.maf), Internet Explorer and Opera use MIME HTML (.mht) and Safari uses its own format (.webarchive) for saving a web page and all of its resources into a single file. So clearly a standard would be beneficial in ensuring archive compatibility between browsers and I think it's suitable for that standard to reside in HTML5. I don't believe this would be very difficult to standardize and the solution may be nothing more than a collection of random files wrapped into a ZIP compressed archive with a unique extension similar to a JAR or ODF file. The unique extension would be recognized by browsers, email clients and editors, which could then extract and display the root file directly (ex. index.html). The root file would obviously contain relative URIs to any other HTML, JavaScript, CSS, images and other files in the archive so the internal structure may not be important and the browser would not need any new rules to interpret individual files once it has uncompressed the archive into memory. This would facilitate passing HTML based documents around that could be viewed with any browser, yet appear as a small single file. There are some specifications for this kind of thing already, e.g. multipart/related (RFC2387), and the derivative MHTML (RFC2557). In HTML5, this can be somewhat achieved using the offline application cache feature, with a cache manifest. But the right solution to address the problems with MHTML are to develop a new RFC that addresses the problems with MHTML, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Editorial: British or American spelling
On Mon, 22 Jan 2007, Elliotte Harold wrote: Is the Web Apps 1.0 spec adhering to British or American spelling? I notice several occurrences of labelled which my dictionaries flag (should be labeled) but I think labelled is correct British spelling. Fixed that particular spelling. Theoretically the spec is US English now, but in practice it's a mixture, and in some cases I intentionally prefer the British spelling. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Differences between application/xhtml+xml and application/xml
body.xhtml (served as application/xhtml+xml)
html xmlns=http://www.w3.org/1999/xhtml;
head
script
window.onload = function() {
alert(document.body);
};
/script
/head
body
/body
/html
body.xml (served as application/xml)
html xmlns=http://www.w3.org/1999/xhtml;
head
script
window.onload = function() {
alert(document.body);
};
/script
/head
body
/body
/html
With the latter, Firefox and Opera don't have document.body defined.
Safari does though.
Should Safari match Firefox and Opera or the other way around?
Either way, could you add a little comment in the spec saying that
although application/xml might work, there are catches.
--
Michael
Re: [whatwg] Web Documents off the Web (was Web Archives)
On Mon, 16 Apr 2007, Tyler Keating wrote: Imagine this: An HTML based document ZIP compressed into a single file could be uploaded as is to the server. Clicking on a link to the file would probably download, decompress and open the file in the browser seamlessly and, even better, right-clicking on the link instead and choosing Download Linked File would download the same nice small single file.** MHTML with a gzip transfer encoding seems like it would do this pretty nicely already, no? On Mon, 16 Apr 2007, Maciej Stachowiak wrote: A cross-browser web archive format sounds like a useful thing. However, I don't think it should be part of or even tied to the HTML spec. In principle, such an archive could contain any browser-viewable content as the root document. This could be HTML, XHTML, SVG, generic XML, plain text, a raster image, or any number of other things. So such an archive format is logically a separate layer and should be specced as such. Indeed, this would belong in another specification. On Tue, 17 Apr 2007, Jon Barnett wrote: What place does HTML5 have in specifying one of these options as a standard archive format? Any? A non-normative section on archives? I don't think we really need to say anything in the spec -- it's a specification, not a position paper. There was much discussion about this topic, but given that I think this is out of scope for HTML5 (and nobody seems to particularly disagree), I haven't responded. Let me know if I missed something that deserved a reply despite the foregoing. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: I've just finished taking a look at the working draft of HTML 5 and thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution of HTML 4, which has both its good and bad points. Accordingly, there are both good and bad parts of the specification. My thoughts are as follows: (I've omitted replies to some parts of your e-mail. I have saved your e-mail for further replies to those sections later.) * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. * The dfn/ is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn't, don't feel bad, most people won't get it. Again, any element that leaves people scratching their heads probably isn't necessary or useful. dfn doesn't have to be used, but for certain cases it's very useful. I don't think it's a problem to keep it. * Speaking of confusing, I've read the section about the meter/ element five times now and still have no idea what it's used for. I don't know how to improve the current text. Does the example showing the newsgroups activity help at all? The real reason for meter is that we need to make sure people don't abuse progress just to show gauges (e.g. disk space usage). Does that make sense? How should we go about better describing this? * I'd like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now). Also contenteditable doesn't solve my issue with rich text editing. It solves the ability to do it, but not a straightforward way to do it in the context of a form and submit it back to the server without some intermediary code. My point is that there should be a way to submit rich text in a form by default, without needing to write extra JavaScript code. The problem is that while everyone seems to want a rich text control, nobody seems to agree on exactly what it should allow. Thus contenteditable, and the ability for people to roll their own. * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data related to an element. I'd propose a reldata attribute (short for related data) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). We recently added data-*=, does that help? http://www.whatwg.org/specs/web-apps/current-work/#data- Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Differences between application/xhtml+xml and application/xml
On Tue, 13 May 2008, Michael A. Puls II wrote: body.xhtml (served as application/xhtml+xml) body.xml (served as application/xml) With the latter, Firefox and Opera don't have document.body defined. Safari does though. Should Safari match Firefox and Opera or the other way around? The HTML5 spec says that Safari is correct. However, none of the browsers implement exactly what the spec requires, which is that all Document objects implement all Document interfaces (SVGDocument, HTMLDocument, etc). Either way, could you add a little comment in the spec saying that although application/xml might work, there are catches. Well, we don't want to start listing the bugs in the spec, that's a losing proposition. :-) The browsers (or the spec) should be fixed so that everything matches. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Documents off the Web (was Web Archives)
2008/5/13 Ian Hickson [EMAIL PROTECTED]: MHTML with a gzip transfer encoding seems like it would do this pretty nicely already, no? Indeed, this would belong in another specification. Yeah, sounds like something for the HTTP layer - what the user-agent will accept. - d.
Re: [whatwg] Thoughts on HTML 5
W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. -- Paweł Stradomski
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Removing @rev is harmful for Lynx because that is how it decides who the author is. At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current document if the author of the document has specified ownership. (Note to authors: if you want to assign the ownership to your document, you need to add into HEAD section a LINK element with appropriate value for REV attribute. Two values are recognized: owner and made (these are case insensitive). For example, HEAD ... LINK REV=made HREF=mailto:[EMAIL PROTECTED] ... HEAD (Attn. lynx-dev: that should be a closing tag!). (http://lynx.isc.org/lynx2.8.6/lynx2-8-6/lynx_help/Lynx_users_guide.html#Mai l) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, May 13, 2008 11:38 AM To: Bjoern Hoehrmann Cc: L. David Baron; [EMAIL PROTECTED] Subject: Re: [whatwg] Configure Apache to send the right MIME type for XHTML On Sun, 11 Mar 2007, Bjoern Hoehrmann wrote: * L. David Baron wrote: My dismissal of XHTML is that the designers of XHTML and related standards are repeatedly introducing more and more incompatibility between XHTML and HTML, which makes it progressively harder for authors to transition to XHTML (particularly to do so gradually on a large site). Out of curiosity, do you dismiss HTML5 on the same grounds? As an example, http://www.bjoernsworld.de/suchmaschinen/robots-txt.html is as close as it comes to a proper HTML document, but to turn it into a HTML5 document I would need to make many non-trivial changes, e.g. find replacements for * link rev We removed rev= because it was only used correctly for one thing (rev=made) and was misused a _lot_, and the number of people using rel=author was comparable (I forget the exact numbers).
Re: [whatwg] Differences between application/xhtml+xml andapplication/xml
I am not sure I understand.
If the document is served as application/xml, should the user agent treat is
as XHTML if appropriate?
OTOH, if the document is served as text/xml, should the user agent obey the
stylesheet processing instruction?
(IIRC, FF ignores the stylesheet if it detects html in a local XML file, as
if served as application/xml according to the recipe above, whereas IE obeys
the inferred document type text/xml rigorously without paying attention to
content.)
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael A. Puls II
Sent: Tuesday, May 13, 2008 12:25 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] Differences between application/xhtml+xml
andapplication/xml
body.xhtml (served as application/xhtml+xml)
html xmlns=http://www.w3.org/1999/xhtml;
head
script
window.onload = function() {
alert(document.body);
};
/script
/head
body
/body
/html
body.xml (served as application/xml)
html xmlns=http://www.w3.org/1999/xhtml;
head
script
window.onload = function() {
alert(document.body);
};
/script
/head
body
/body
/html
With the latter, Firefox and Opera don't have document.body defined.
Safari does though.
Should Safari match Firefox and Opera or the other way around?
Either way, could you add a little comment in the spec saying that
although application/xml might work, there are catches.
--
Michael
Re: [whatwg] createImageData
On May 10, 2008, at 4:53 PM, Vladimir Vukicevic wrote: I would amend the spec to state that if an object is passed to putImageData with the necessary properties, but without having been created by create/getImageData beforehand, that its dimensions are aways in device pixels. Some suggested language in section 3.12.11.1.11(!): Instead of: If the first argment to the method is null or not an ImageData object that was returned by createImageData() or getImageData() then the putImageData() method must raise a TYPE_MISMATCH_ERR exception. I would suggest: The first argument to the method must be an ImageData object returned by createImageData(), getImageData(), or an object constructed with the necessary properties by the user. If the object was constructed by the user, its width and height dimensions are specified in device pixels (which may not map directly to CSS pixels). If null or any other object is given that does not present the ImageData interface, then the putImageData() method must raise a TYPE_MISMATCH_ERR exception. - Vlad
Re: [whatwg] createImageData
On May 13, 2008, at 1:53 PM, Vladimir Vukicevic wrote: The first argument to the method must be an ImageData object returned by createImageData(), getImageData(), or an object constructed with the necessary properties by the user. If the object was constructed by the user, its width and height dimensions are specified in device pixels (which may not map directly to CSS pixels). If null or any other object is given that does not present the ImageData interface, then the putImageData() method must raise a TYPE_MISMATCH_ERR exception. If we were to add that we should include a note to indicate that using a custom object is not recommended -- Any code that uses a custom created object will never benefit from improvements in ImageData performance made by the UA. That said I still don't believe custom objects should be allowed, aside from the resolution (which may or may not be relevant) and performance issues, a custom object with a generic JS array, rather than an ImageData object will have different behaviour -- a proper ImageData will clamp on assignment, and throw in cases that a custom object won't. - Vlad --Oliver
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
On Tue, 13 May 2008, Křištof Želechovski wrote: Removing @rev is harmful for Lynx because that is how it decides who the author is. At any time while viewing documents within Lynx, you may use the 'c' command to send a mail message to the owner of the current document if the author of the document has specified ownership. (Note to authors: if you want to assign the ownership to your document, you need to add into HEAD section a LINK element with appropriate value for REV attribute. Two values are recognized: owner and made (these are case insensitive). For example, HEAD ... LINK REV=made HREF=mailto:[EMAIL PROTECTED] Removing rev= from the spec doesn't preclude Lynx still supporting it for legacy documents, and for new documents, rel=author is preferred and is trivially supportable given support for rev=made, so I don't think this is a particularly convincing argument. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createImageData
On May 13, 2008, at 2:58 PM, Oliver Hunt wrote: On May 13, 2008, at 1:53 PM, Vladimir Vukicevic wrote: The first argument to the method must be an ImageData object returned by createImageData(), getImageData(), or an object constructed with the necessary properties by the user. If the object was constructed by the user, its width and height dimensions are specified in device pixels (which may not map directly to CSS pixels). If null or any other object is given that does not present the ImageData interface, then the putImageData() method must raise a TYPE_MISMATCH_ERR exception. If we were to add that we should include a note to indicate that using a custom object is not recommended -- Any code that uses a custom created object will never benefit from improvements in ImageData performance made by the UA. I'm fine with adding that language (the first part, anyway); something like Using a custom object is not recommended as the UA may be able to optimize operations using ImageData if they were created via createImageData() or getImageData(). That said I still don't believe custom objects should be allowed, aside from the resolution (which may or may not be relevant) and performance issues, a custom object with a generic JS array, rather than an ImageData object will have different behaviour -- a proper ImageData will clamp on assignment, and throw in cases that a custom object won't. That verification seems odd; doing those checks (clamping, conversion to number) on every single pixel assignment is going the wrong direction for performance -- you really want to validate everything at once. - Vlad
Re: [whatwg] createImageData
That said I still don't believe custom objects should be allowed, aside from the resolution (which may or may not be relevant) and performance issues, a custom object with a generic JS array, rather than an ImageData object will have different behaviour -- a proper ImageData will clamp on assignment, and throw in cases that a custom object won't. That verification seems odd; doing those checks (clamping, conversion to number) on every single pixel assignment is going the wrong direction for performance -- you really want to validate everything at once. But by delaying clamping, etc you are requiring that the backing store be an array of boxed values, leading to increased memory usage, increased indirection, and increasing the cost of the final blit. My experience implementing this in WebKit showed a pure byte array backing store was significantly faster than using boxed values. - Vlad --Oliver
Re: [whatwg] createImageData
On May 13, 2008, at 3:37 PM, Oliver Hunt wrote: That said I still don't believe custom objects should be allowed, aside from the resolution (which may or may not be relevant) and performance issues, a custom object with a generic JS array, rather than an ImageData object will have different behaviour -- a proper ImageData will clamp on assignment, and throw in cases that a custom object won't. That verification seems odd; doing those checks (clamping, conversion to number) on every single pixel assignment is going the wrong direction for performance -- you really want to validate everything at once. But by delaying clamping, etc you are requiring that the backing store be an array of boxed values, leading to increased memory usage, increased indirection, and increasing the cost of the final blit. That's an implementation detail, I guess.. My experience implementing this in WebKit showed a pure byte array backing store was significantly faster than using boxed values. Faster for which operation, though? The put, or the actual manipulation? It's a tradeoff, really; if you're doing limited pixel manipulation, but lots of putImageData, you can optimize that directly by just calling putImageData once to an offscreen canvas and then blitting that with drawImage. If you're doing lots of pixel manipulation but only one putImageData, I guess you can use a JS array for your intermediate ops to avoid the checking overhead, and set the image data pixels all at once (though again paying the checking penalty per pixel), but having cheap putImageData. Throwing the error at putImageData time lets the implementation optimize in whatever way is most convenient/performant (either at pixel operation time by setting an error bit in the ImageData object which is checked by putImageData, or at putImageData time), and is (IMO) more flexible.. given that errors are an exceptional case, I don't think the spec should force the checking per pixel. - Vlad
Re: [whatwg] createImageData
My experience implementing this in WebKit showed a pure byte array backing store was significantly faster than using boxed values. Faster for which operation, though? The put, or the actual manipulation? It's a tradeoff, really; if you're doing limited pixel manipulation, but lots of putImageData, you can optimize that directly by just calling putImageData once to an offscreen canvas and then blitting that with drawImage. If you're doing lots of pixel manipulation but only one putImageData, I guess you can use a JS array for your intermediate ops to avoid the checking overhead, and set the image data pixels all at once (though again paying the checking penalty per pixel), but having cheap putImageData. Throwing the error at putImageData time lets the implementation optimize in whatever way is most convenient/performant (either at pixel operation time by setting an error bit in the ImageData object which is checked by putImageData, or at putImageData time), and is (IMO) more flexible.. given that errors are an exceptional case, I don't think the spec should force the checking per pixel. I found it faster in general across quite a few tests. I would argue that if you are using ImageData in a way that leads to you writing to the same pixel multiple times you should improve your algorithms (this is just the generic over painting issue). A very reall issue to consider though is the case where I've been very careful to only update those pixels that need to be updated. If the ImageData is not clamped, etc on put then *every* blit must do a complete revalidation of the entire ImageData data buffer. I think we need a list of use cases for ImageData, off the top of my head i can think of: * filters -- in general a single write per pixel, potentially multiple reads * Generated images -- still arguably single write per pixel * I'm not sure what to call this -- but things like http://jsmsxdemo.googlepages.com/jsmsx.html I honestly can't think of something that would (sanely) expect to be writing multiple times to the same pixel between blits, but i should note i haven't actively spent any significant time trying to come up with these. That said in all of the above cases the cost of immediate clamping is technically the same as delaying the clamp, although it also has the benefit of allowing reduced memory usage. - Vlad --Oliver
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 6:09 PM To: Paweł Stradomski [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Thoughts on HTML 5 On Tue, 13 May 2008, Paweł Stradomski wrote: W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). The only synonym of dialog that is anywhere near as general seems to be discourse/. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling.
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: The only synonym of dialog that is anywhere near as general seems to be discourse/. I dunno, that just sounds so formal. I agree that dialog isn't perfect and could be (and has been) confused with dialog boxes, but I'm not convinced it's not the best name for the job anyway. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling. Experience with language= on script suggests that many authors have serious difficulties spelling words that contain the gu letter pair. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createImageData
On May 13, 2008, at 4:10 PM, Oliver Hunt wrote: My experience implementing this in WebKit showed a pure byte array backing store was significantly faster than using boxed values. Faster for which operation, though? The put, or the actual manipulation? It's a tradeoff, really; if you're doing limited pixel manipulation, but lots of putImageData, you can optimize that directly by just calling putImageData once to an offscreen canvas and then blitting that with drawImage. If you're doing lots of pixel manipulation but only one putImageData, I guess you can use a JS array for your intermediate ops to avoid the checking overhead, and set the image data pixels all at once (though again paying the checking penalty per pixel), but having cheap putImageData. Throwing the error at putImageData time lets the implementation optimize in whatever way is most convenient/performant (either at pixel operation time by setting an error bit in the ImageData object which is checked by putImageData, or at putImageData time), and is (IMO) more flexible.. given that errors are an exceptional case, I don't think the spec should force the checking per pixel. I found it faster in general across quite a few tests. I would argue that if you are using ImageData in a way that leads to you writing to the same pixel multiple times you should improve your algorithms (this is just the generic over painting issue). I dunno, some kind of iterative algorithm that you want to visualize at random timesteps. You could keep the output in a separate array and copy over when you want to render it. A very reall issue to consider though is the case where I've been very careful to only update those pixels that need to be updated. If the ImageData is not clamped, etc on put then *every* blit must do a complete revalidation of the entire ImageData data buffer. Yep, that's true. I think we need a list of use cases for ImageData, off the top of my head i can think of: * filters -- in general a single write per pixel, potentially multiple reads * Generated images -- still arguably single write per pixel * I'm not sure what to call this -- but things like http://jsmsxdemo.googlepages.com/jsmsx.html I honestly can't think of something that would (sanely) expect to be writing multiple times to the same pixel between blits, but i should note i haven't actively spent any significant time trying to come up with these. That said in all of the above cases the cost of immediate clamping is technically the same as delaying the clamp, although it also has the benefit of allowing reduced memory usage. Yeah, those are all good use cases -- it just seems like requiring immediate clamping is basically specifying for a specific implementation, when the overall goal is checking for invalid data. Specifying that the error should come from putImageData would give implementations more flexibility, without limiting error checking. (You could argue that it's easier to get a precise error location by checking on pixel assignment, but I don't think that the potential cost and loss of flexibility is worth it. Once authors know that they have an error in their data, they can take other action to track it down.) - Vlad
Re: [whatwg] createImageData
On May 13, 2008, at 4:28 PM, Vladimir Vukicevic wrote: On May 13, 2008, at 4:10 PM, Oliver Hunt wrote: My experience implementing this in WebKit showed a pure byte array backing store was significantly faster than using boxed values. Faster for which operation, though? The put, or the actual manipulation? It's a tradeoff, really; if you're doing limited pixel manipulation, but lots of putImageData, you can optimize that directly by just calling putImageData once to an offscreen canvas and then blitting that with drawImage. If you're doing lots of pixel manipulation but only one putImageData, I guess you can use a JS array for your intermediate ops to avoid the checking overhead, and set the image data pixels all at once (though again paying the checking penalty per pixel), but having cheap putImageData. Throwing the error at putImageData time lets the implementation optimize in whatever way is most convenient/performant (either at pixel operation time by setting an error bit in the ImageData object which is checked by putImageData, or at putImageData time), and is (IMO) more flexible.. given that errors are an exceptional case, I don't think the spec should force the checking per pixel. I found it faster in general across quite a few tests. I would argue that if you are using ImageData in a way that leads to you writing to the same pixel multiple times you should improve your algorithms (this is just the generic over painting issue). I dunno, some kind of iterative algorithm that you want to visualize at random timesteps. You could keep the output in a separate array and copy over when you want to render it. I'm not sure what you mean. By my interpretation that would require more work when you validate on blit, because while you would not have to validate when you copy the invalidated region of your buffer into the ImageData buffer it would not need to be validated, but when you then go to blit the ImageData, putImageData *must* revalidate the entirety of the ImageData buffer (hmmm, i suppose the UA could try tracking dirty regions in the ImageData buffer to minimise revalidation? i suspect this would not be significantly better than just validating on every pixel put) If you actually meant you were using the ImageData buffer as your working buffer then you would possibly be doing excessive revalidation, but in my experience such a case would be atypical (and we're more interested in the performance of the normal case vs. edge cases) and the cost of clamping, etc is dwarfed by the dispatch cost just to do the assignment (at least in WebKit) so i'm not sure there would a significant loss in performance anyway. A very reall issue to consider though is the case where I've been very careful to only update those pixels that need to be updated. If the ImageData is not clamped, etc on put then *every* blit must do a complete revalidation of the entire ImageData data buffer. Yep, that's true. I think we need a list of use cases for ImageData, off the top of my head i can think of: * filters -- in general a single write per pixel, potentially multiple reads * Generated images -- still arguably single write per pixel * I'm not sure what to call this -- but things like http://jsmsxdemo.googlepages.com/jsmsx.html I honestly can't think of something that would (sanely) expect to be writing multiple times to the same pixel between blits, but i should note i haven't actively spent any significant time trying to come up with these. That said in all of the above cases the cost of immediate clamping is technically the same as delaying the clamp, although it also has the benefit of allowing reduced memory usage. Yeah, those are all good use cases -- it just seems like requiring immediate clamping is basically specifying for a specific implementation, when the overall goal is checking for invalid data. Specifying that the error should come from putImageData would give implementations more flexibility, without limiting error checking. (You could argue that it's easier to get a precise error location by checking on pixel assignment, but I don't think that the potential cost and loss of flexibility is worth it. Once authors know that they have an error in their data, they can take other action to track it down.) There is no implementor freedom here -- you either clamp immediately, or you do not clamp immediately, if one UA does not clamp then it will have different behaviour from the other UAs leading to behavioural incompatibility (eg. one site may expect the values to be clamped immediately, and therefore not work in UAs that don't clamp, another may believe that the clamping happens later leading it to break in those UAs that clamp immediately). This is not to say there's no room for implementation variation -- an implementation *could* maintain the data as
Re: [whatwg] createImageData
On May 13, 2008, at 4:28 PM, Vladimir Vukicevic wrote: On May 13, 2008, at 4:10 PM, Oliver Hunt wrote: I think we need a list of use cases for ImageData, off the top of my head i can think of: * filters -- in general a single write per pixel, potentially multiple reads * Generated images -- still arguably single write per pixel * I'm not sure what to call this -- but things like http://jsmsxdemo.googlepages.com/jsmsx.html I honestly can't think of something that would (sanely) expect to be writing multiple times to the same pixel between blits, but i should note i haven't actively spent any significant time trying to come up with these. That said in all of the above cases the cost of immediate clamping is technically the same as delaying the clamp, although it also has the benefit of allowing reduced memory usage. Yeah, those are all good use cases -- it just seems like requiring immediate clamping is basically specifying for a specific implementation, when the overall goal is checking for invalid data. Specifying that the error should come from putImageData would give implementations more flexibility, without limiting error checking. Wouldn't delaying clamping and error checking make it hard to use a native pixel data array as the ImageData backing store? In fact it would make it pretty much impossible unless you at least clamp/round/ throw when reading the data from JS. And even then, such an ImageData implementation would have to taint itself to record whether an error had occurred. Regards, Maciej
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: I agree that the word discourse is more formal than dialog, but it does cover both formal and informal speech unlike some other thesaurus inspired possibilities such as colloquy or chat. Sure, I'm just reluctanct to use an element name that is too formal, as (for better or worse) that makes the language sound stilted. It does have the advantage over dialog of avoiding the spelling issue and the computer term issue. If those issues end up being judged sufficient to make dialog/ undesirable, then discourse/ seems to me to be the best alternative available among English words. Of course, if words were abandoned altogether d/ would also be a possibility. d is probably too short for an element that won't be used that much. Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] script charset=
On Mon, 25 Apr 2005, Toshirou Takahashi wrote:
about 2.12. Scripting
http://whatwg.org/specs/web-apps/current-work/#the-script
interface HTMLScriptElement : HTMLElement {
attribute DOMString text;
attribute DOMString src;
attribute DOMString type;
};
Why isn't there Charset attribute ?
I've added it.
I haven't tested where UAs get their charset= information from in
detail. The spec, as defined now, makes the charset= attribute
authoritative, and if the attribute is omitted, makes document.charset the
required authoritative default. Is that what browsers do?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 8:08 PM Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. Is there any reasonable chance an element for a dialog box might end up being added to XForms? (There is a proposal mentioned on the XForms wiki [1] for a possible dialog element for XForms 2.0, but I have no idea how much of a chance that proposal has as opposed to extending the message element.) I know that XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem for those that will be using various flavors of XHTML with XForms is worth addressing now. If XForms were to add an explicit dialog box element, what name other than dialog/ would be appropriate? [1] http://www.w3.org/MarkUp/Forms/wiki/Dialogs
Re: [whatwg] Web Archives
Le 13 mai 2008 à 18:55, Ian Hickson a écrit : On Wed, 11 Apr 2007, Tyler Keating wrote: Currently, I know that Firefox uses Mozilla Archive Format (.maf), Internet Explorer and Opera use MIME HTML (.mht) and Safari uses its own format (.webarchive) for saving a web page and all of its resources into a single file. So clearly a standard would be beneficial in ensuring archive compatibility between browsers and I think it's suitable for that standard to reside in HTML5. […] There are some specifications for this kind of thing already, e.g. multipart/related (RFC2387), and the derivative MHTML (RFC2557). See Widgets 1.0: Packaging and Configuration http://www.w3.org/TR/widgets/ Abstract This document defines a Zip-based packaging format and an XML-based configuration document format for widgets. The configuration document is a simple XML-based language that authors can use to record metadata and configuration parameters about a widget. The packaging format is a container for files required by a widget. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Re: [whatwg] Thoughts on HTML 5
Le 14 mai 2008 à 07:09, Ian Hickson a écrit : That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). food for thoughts * colloquy * conversation (probably too long) * chat (probably too IRC, messenger oriented, though here I suspect my own distortion field. People often says let's have a chat.) * dialogue (was wondering if it was less geeky than dialog, not sure) * discourse * speech * talking * converse -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Re: [whatwg] Thoughts on HTML 5 - dialog
FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. [1]http://developer.mozilla.org/en/docs/XUL:dialog On Tue, May 13, 2008 at 8:08 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 13 May 2008, Ernest Cline wrote: I agree that the word discourse is more formal than dialog, but it does cover both formal and informal speech unlike some other thesaurus inspired possibilities such as colloquy or chat. Sure, I'm just reluctanct to use an element name that is too formal, as (for better or worse) that makes the language sound stilted. It does have the advantage over dialog of avoiding the spelling issue and the computer term issue. If those issues end up being judged sufficient to make dialog/ undesirable, then discourse/ seems to me to be the best alternative available among English words. Of course, if words were abandoned altogether d/ would also be a possibility. d is probably too short for an element that won't be used that much. Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Zach Carter
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. Is there any reasonable chance an element for a dialog box might end up being added to XForms? (There is a proposal mentioned on the XForms wiki [1] for a possible dialog element for XForms 2.0, but I have no idea how much of a chance that proposal has as opposed to extending the message element.) I know that XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem for those that will be using various flavors of XHTML with XForms is worth addressing now. If XForms were to add an explicit dialog box element, what name other than dialog/ would be appropriate? There are a number of other much more important conflicts between XForms and HTML at this point, I don't think this is a particularly big concern. On Wed, 14 May 2008, Karl Dubost wrote: food for thoughts * conversation (probably too long) * chat (probably too IRC, messenger oriented, though here I suspect my own distortion field. People often says let's have a chat.) * dialogue (was wondering if it was less geeky than dialog, not sure) * discourse These have been suggested in recent threads. * colloquy I would imagine this would confuse more people than dialog. * speech This has the same problem as talk, which was also suggested recently. * talking * converse These are not in the same style (nouns) as other tags, which would lead to a language consistency problem. On Tue, 13 May 2008, Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
