Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan da...@davidflanagan.com wrote: Erik Arvidsson wrote: [snip] Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? This makes it clear that a collection is not an array, but clearly defines a way to obtain an array. Clever implementors might even be able to optimize common uses-cases using some kind of copy-on-write strategy so that toArray() doesn't involve memory allocation and copying. That would solve the OP's problem, but what about other collections like NodeList, StyleSheetList, and CSSStyleDeclaration? An interface that has a toArray() method might be more suitable, as it could be added arbitrarily to other interfaces mentioned already. In any case, the problem is not going to go away in IE6. Nor IE7. Nor IE8. IE9 might change to implement Host object collections as native ECMAScript objects, but even then, then the problems will still need to be addressed in all versions of IE prior. MSIE's implementation of Host objects WRT Array generics is a fundamental and significant and important problem that needs to be addressed. If Internet Explorer's problems with Host objects cannot be fixed, then it would be a nice feature to have a way to get an array from a collection. However, Microsoft should release an IE9 where host object collections are implemented as native ECMAscript objects. If they can do that, the problems would not be an issue. What do you say, Travis Leithead and IE Team? Will you release IE9 with host object implemented as native EcmaScript objects? Garrett
Re: [whatwg] Dealing with Stereoscopic displays
Hi Rob, all, Fair enough :-) I'll have to try better. Rob you give some good examples (WebGL and CSS3) of how an application could be built which correctly renders two views with stereopsis. However, with the exception of Anaglyph methods, a user will need specialised display hardware to properly view the image. So, to clarify, the issue is not the rendering of the stereo views (I'll worry about that later) but rather how those views are targeted to the correct virtual display (for example by alternating the left and right views on odd and even frames). If we take the case of the Blu-Ray 3D specification it is neutral about how the hardware is implemented, but the hardware is expected to respect the flags indicating whether a frame is for the left or right virtual display. In order to work with HTML the UA has to have some awareness of the hardware and way of signalling with view is for which virtual display. My question is, how can this be done in a consistent manner? Given that this usually requires some hardware control, is a good approach to use the device element? I hope this is a little clearer. Best regards, Eoin. On Tue, Apr 27, 2010 at 10:01 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Apr 27, 2010 at 8:38 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: * A user visits the National Museum site and wants to see a time-machine view of objects in the collection with a sense of 3D depth based on their age I think this is the closest you get to an actual use-case :-). The rest is mixed up with information about possible solutions. Also, it's highly unlikely the a user will visit your site with a fully formed desire to view objects in a collection with a sense of 3D depth based on their age :-). But let's say the authors of that site want to visualize objects in the collection with different objects at different depths. It seems to me either WebGL or CSS 3D transforms --- or a mixture --- could be used for this, maybe with some extra information provided to identity the camera positions for rendering the stereo views. Actually, I probably shouldn't be involved in this discussion since I'm monocular :-). 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] -- Eoin Kilfeather Digital Media Centre Dublin Institute of Technology
[whatwg] WebSocket leading 0x80 bytes in length
The WebSocket spec allows leading 0x80 bytes in the length of a binary frame. Such bytes do not change the value of the length. In order to not have to deal with ridiculous cases such as when there are 50k such bytes, we would want to fail the connection if the first byte in length is 0x80. Allowing it also complicates the check of the closing handshake (if we want 0xFF 0x80 0x00 to not count as a closing handshake). -- Simon Pieters Opera Software
Re: [whatwg] Dealing with Stereoscopic displays
On Wed, Apr 28, 2010 at 8:09 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: If we take the case of the Blu-Ray 3D specification it is neutral about how the hardware is implemented, but the hardware is expected to respect the flags indicating whether a frame is for the left or right virtual display. In order to work with HTML the UA has to have some awareness of the hardware and way of signalling with view is for which virtual display. Sure, but this seems like a UA-specific issue that the Web author should not need to worry about. UAs already coordinate with the underlying software and hardware platform to render Web content. 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] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
Le 28/04/2010 00:03, Garrett Smith a écrit : On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan da...@davidflanagan.com wrote: Erik Arvidsson wrote: [snip] Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? This makes it clear that a collection is not an array, but clearly defines a way to obtain an array. Clever implementors might even be able to optimize common uses-cases using some kind of copy-on-write strategy so that toArray() doesn't involve memory allocation and copying. That would solve the OP's problem, but what about other collections like NodeList, StyleSheetList, and CSSStyleDeclaration? I am sorry, I don't know what OP stands for. An interface that has a toArray() method might be more suitable, as it could be added arbitrarily to other interfaces mentioned already. I agree with this idea and proposed something in that direction recently : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/026057.html In any case, the problem is not going to go away in IE6. Nor IE7. Nor IE8. IE9 might change to implement Host object collections as native ECMAScript objects, but even then, then the problems will still need to be addressed in all versions of IE prior. In this case, what do you refer as the problem ? When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. MSIE's implementation of Host objects WRT Array generics is a fundamental and significant and important problem that needs to be addressed. If Internet Explorer's problems with Host objects cannot be fixed, then it would be a nice feature to have a way to get an array from a collection. The idea of getting an Array from a collection came out without IE in mind. If we want to have it in a specification, it has to be a good idea regardless browsers specificities. However, Microsoft should release an IE9 where host object collections are implemented as native ECMAscript objects. If they can do that, the problems would not be an issue. What do you say, Travis Leithead and IE Team? Will you release IE9 with host object implemented as native EcmaScript objects? I have not seen any Travis Leithead or IE Team in the recipients. Is that normal ? David
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection
On 27/04/10 20:23, David Bruant wrote:
Le 27/04/2010 03:54, Geoffrey Sneddon a écrit :
On 26/04/10 19:50, And Clover wrote:
David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays,
how about just giving them a toArray() method?
I like that, as a practical and explicit (JavaScript-specific)
binding.
In the longer term, what's the thinking on a more basic change:
- Require specific DOM interfaces like NodeList, HTMLCollection,
Element etc. to be available for prototype monkey-patching under
their interface names as properties of `window`?
Then we wouldn't have to worry about what Array-like methods need
to be provided on HTMLCollection, because application and
framework authors could choose whichever they liked to prototype
in.
IE8/Moz/Op/Saf/Chr already do this to a significant extent, but
there's no standard that says they have to. It would allow DOM
extension to be put on a much less shaky footing than the messy
hack Prototype 1.x uses.
Is this something that's a reasonable requirement for browsers in
future?
HTML5 through WebIDL and its ECMAScript binding already does
require this.
I can see where interfaces are expected to be exposed
([NamedConstructor]) in the global object, but I don't see where it
is said that the prototype of the constructor must be extensible. I
don't even see this in the section which is the relevent one in my
opinion (Interface prototype object) I have read this version of
WebIDL : http://dev.w3.org/2006/webapi/WebIDL/
Section 4.1.1 Interface object:
The interface object MUST also have a property named prototype with
attributes { DontDelete, ReadOnly } whose value is an object called
the interface prototype object. This object provides access to the
functions that correspond to the operations defined on the interface,
and is described in more detail in section 4.4.3 below.
--
Geoffrey Sneddon — Opera Software
http://gsnedders.com/
http://www.opera.com/
Re: [whatwg] Dealing with Stereoscopic displays
Well, I agree that the web author shouldn't worry about how it is achieved, but would it not be the case that the author needs to indicate which view is for which display? That is to say the author would be required to flag the output for correct routing to the virtual display. Is it beyond the scope to the specification to indicate a normative way of doing this? Best, Eoin On Wed, Apr 28, 2010 at 9:17 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Apr 28, 2010 at 8:09 PM, Eoin Kilfeather ekilfeat...@dmc.dit.iewrote: If we take the case of the Blu-Ray 3D specification it is neutral about how the hardware is implemented, but the hardware is expected to respect the flags indicating whether a frame is for the left or right virtual display. In order to work with HTML the UA has to have some awareness of the hardware and way of signalling with view is for which virtual display. Sure, but this seems like a UA-specific issue that the Web author should not need to worry about. UAs already coordinate with the underlying software and hardware platform to render Web content. 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] -- Eoin Kilfeather Digital Media Centre Dublin Institute of Technology
Re: [whatwg] Dealing with Stereoscopic displays
On 04/28/2010 10:39 AM, Eoin Kilfeather wrote: Well, I agree that the web author shouldn't worry about how it is achieved, but would it not be the case that the author needs to indicate which view is for which display? That is to say the author would be required to flag the output for correct routing to the virtual display. Is it beyond the scope to the specification to indicate a normative way of doing this? I think the idea is that rather than the author manually producing different content for each display, the 3D positional information in the underlying format (e.g. WebGL) would be used by the browser to automatically create a 3D view on the hardware available.
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. Of course there is nothing wrong with making the syntax more natural if it can be done in a suitably web-compatible way. However it seems more sensible to do this at a lower level e.g. as part of Web DOM Core. Sadly that spec is in need of an editor.
[whatwg] link by name instead of url
This is an idea I've had in my head for a while and I think it might make an useful addition to HTML5 standard. As this is just an idea I didn't work out all the details. I'm just looking to see if this is something that might be accepted. Use case 1: A document author wants to provide a link to some site. This site has multiple versions of the page depending on where you live (think google.co.uk, google.co.hk, google.com etc) Use case 2: A document author wants to ask users to share his page via the users preferred social network. Something like Please a href=http://facebook.com;tell your friends/a about this site! Use case 3: A document author wants to provide a link to search for more information on a preferred search engine. I'd like to leverage the user's bookmarks in these cases by allowing authors to specify markup like case 1: a goto=googlegoogle/a case 2: a goto=social-networktell your friends/a case 3: a goto=searchsearch!a The UA would be responsible for determining which site to link to. A href could be provided as a fallback for old browsers or for sites where the user did not yet make a choice.
Re: [whatwg] link by name instead of url
On Wed, 2010-04-28 at 12:45 +0300, Eitan Adler wrote: This is an idea I've had in my head for a while and I think it might make an useful addition to HTML5 standard. As this is just an idea I didn't work out all the details. I'm just looking to see if this is something that might be accepted. Use case 1: A document author wants to provide a link to some site. This site has multiple versions of the page depending on where you live (think google.co.uk, google.co.hk, google.com etc) Use case 2: A document author wants to ask users to share his page via the users preferred social network. Something like Please a href=http://facebook.com;tell your friends/a about this site! Use case 3: A document author wants to provide a link to search for more information on a preferred search engine. I'd like to leverage the user's bookmarks in these cases by allowing authors to specify markup like case 1: a goto=googlegoogle/a case 2: a goto=social-networktell your friends/a case 3: a goto=searchsearch!a The UA would be responsible for determining which site to link to. A href could be provided as a fallback for old browsers or for sites where the user did not yet make a choice. case 1: I don't think a browser could be that aware of a website. While you see google.co.uk and google.cn as just different language versions of the same site, a browser see's two different domain names entirely. I think it's a dangerous assumption to just link the two domains by their first parts, as that is no guarantee that they are the same site or even owned by the same people, and the whois for a domain isn't always reliable as registrars often register a domain in their company name rather than for the individual. case 2: each of these types of social sharing sites tends to have their own mechanism for sharing content which is generally in the form of a link. A UA would have to be aware of each specific one and the format of URL to pass them. This would potentially lead to some sites not offering links to share to certain websites because the UA isn't aware of them. case 3: I'm not sure this offers anything that a user can't already easily get themselves. Most browsers now allow multiple search engines to be attached and swapped in and out easily. For example, in Firefox I can easily switch between searching Google, Dictionary.com or Wikipedia. It wouldn't make sense for most websites to offer anything but the first one out of my list of three there. Often as well, a website might have a particular reason for delivering traffic to a specific search engine. A site that uses Google as a mechanism for searching it's own site might naturally offer this as an option to search the Web (if it offered this at all, which seems a strange thing to do anyway) Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] img as a layout tool to describe the displayed region of a CSS background-image
http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Thanks. -- Ingo Chao http://www.satzansatz.de/
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
On Wed, 2010-04-28 at 13:31 +0200, Ingo Chao wrote: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Thanks. If an image is transparent, it has no display value other than to reserve an area of space, which goes back to the original point that images should not be used for layout. If you're using a background image then that shouldn't need to convey any meaning to the viewer, it should only be for presentation purposes. The meaning of the content should remain the same if the background image is displayed or turned off regardless. You should consider re-structuring your page so that the presentation is separate from the content. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
I believe the spec is trying to stigmatize old-times spacer images used to layout other HTML elements, like img src=spacer.gif width=100 height=1 which are overly ugly and meaningless now that there's nothing you can't layout by CSS. -- G Ingo Chao wrote, On 28/04/2010 13.31: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Thanks.
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
On Wed, 2010-04-28 at 13:41 +0200, Giorgio Maone wrote: I believe the spec is trying to stigmatize old-times spacer images used to layout other HTML elements, like img src=spacer.gif width=100 height=1 which are overly ugly and meaningless now that there's nothing you can't layout by CSS. -- G Ingo Chao wrote, On 28/04/2010 13.31: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Thanks. But still, using a transparent image with some alt text to convey information about a background image is just as bad. It's breaking the relationship between content and the meaning of that content. A background image should be just that, and shouldn't have any impact on the meaning of information. Likewise, colour shouldn't be relied on to convey information, as there are cases where colours can't be displayed or aren't transferred if the information is grabbed as an excerpt to be used elsewhere. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Dealing with Stereoscopic displays
On 2010-04-27 00:59, Robert O'Callahan wrote: I think it's interesting to think about what browsers could do with stereo output. We already have three features that could produce useful stereo output today: 1) WebGL 2) CSS 3D Transforms 3)video (assuming there was some kind of 3D video format defined elsewhere) Of those, I think 3D video is perhaps the most significant, followed by WebGL for, e.g. 3D games. But I don't think these are issues that should be addressed by the WHATWG or HTMLWG at this stage, particularly for video. 3D video would depend on the availability of a suitable 3D video codec that can be implemented by browsers. Something like h.264 MVC (Multiview Video Coding) as used by 3D Blu-ray would be nice, but we would need something that is royalty free. I don't know of any other 3D video codec, especially not among the royalty free choices. I think this issue should be revisited in the future if and when such a codec becomes available. But given that the the actual video rendering is handled by the implementation, completely transparently from the DOM API, the current markup and DOM API should be sufficient for basic playback support. 3D Enhancements to the DOM API and markup can be considered later if necessary, such as figuring out how to deal with drawing an HTMLVideoElement playing a 3D video onto a 2D canvas. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] WebSocket leading 0x80 bytes in length
On Wed, 28 Apr 2010 10:15:13 +0200, Simon Pieters sim...@opera.com wrote: The WebSocket spec allows leading 0x80 bytes in the length of a binary frame. Such bytes do not change the value of the length. In order to not have to deal with ridiculous cases such as when there are 50k such bytes, we would want to fail the connection if the first byte in length is 0x80. This is now sunk cost for us. Please disregard. Allowing it also complicates the check of the closing handshake (if we want 0xFF 0x80 0x00 to not count as a closing handshake). -- Simon Pieters Opera Software
Re: [whatwg] Directory upload via input type=file directory
Also, I do believe the ability to upload a whole directory is important for some good use-cases, e.g. upload a directory of photos to a photo site while maintaing directory structure. I can't really say that I can think of any very urgent use cases for this. However only a minor tweak to specs would cover this. By allowing the filename to contain a partial path you'd have this covered without need for new input types. I think this has been discussed before. Yes, the path information can be stored and communicated with a small tweak, let's take that as settled. Assuming the use case is valid to upload an entire directory while maintaining directory structure, how should the user choose the directory? That's the point I'm interested in settling and I think we've mostly just circled around it. Suggestions include: - Open up a system folder-picker dialog. The UA needs to know when to open that dialog instead of a file-picker dialog, the two dialogs being different on all major platforms, and so we could: - use a new 'directory' attribute on input to indicate it (my original proposal) - use multiple buttons (add file(s)/add folder/remove) with each input multiple that allows the user to do different things - Create a new file-picker for input multiple that allows both file and folder selection (i think most people want to avoid this) - Ojan's proposal: allow a folder to be dragged onto a input multiple tag, but don't allow specifying through dialogs. Clearly there are options without the new attribute, but I still think they all result in awkward UI. I don't think allowing drag and drop only would be sufficient especially considering accessibility. -John
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
On 28/04/2010, at 7:43 PM, Tab Atkins Jr. wrote: On Wed, Apr 28, 2010 at 4:31 AM, Ingo Chao i4c...@googlemail.com wrote: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. I think this may be a little vague/broad. I understand the intention, but say for example I have a logo image in the top left of my header, and my header doesn't have a static height set (in case something in the header needs it to grow or shrink for instance), then the height of the logo image is dictating the height of its parent, and this would seem to me, to be using an img as a layout tool, in a sense. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Sprites for icons, while widely used and considered fairly good practice, still seem pretty hack-ish to me. Icons can (arguably) help convey meaning in a document, and changing a background position to change that meaning doesn't seem like the best way of achieving this. I am of course thinking like 10 years into the future here, as sprites are perfectly fine for lots of uses today, but as concurrent connections become less of a problem, I think lots of us will look back on sprites the same way we see spacer.gifs, which were a necessary evil at the time. - Steve Dennis Yes, this is using the img as a layout tool. Specifically, you're using the img to avoid specifying width and height in CSS, and to enable further layout hacks with sprites using background-positioning. ~TJ
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
On Wed, Apr 28, 2010 at 1:04 PM, Steve Dennis ad...@subcide.com wrote: On 28/04/2010, at 7:43 PM, Tab Atkins Jr. wrote: On Wed, Apr 28, 2010 at 4:31 AM, Ingo Chao i4c...@googlemail.com wrote: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. I think this may be a little vague/broad. I understand the intention, but say for example I have a logo image in the top left of my header, and my header doesn't have a static height set (in case something in the header needs it to grow or shrink for instance), then the height of the logo image is dictating the height of its parent, and this would seem to me, to be using an img as a layout tool, in a sense. Don't overthink it. It's a very simple rule. ^_^ Having an img *interact* in the layout is both fine and obviously necessary. The restriction is to prevent someone from using an img element *solely* for layout purposes. ~TJ
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
2010/4/28 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Apr 28, 2010 at 1:04 PM, Steve Dennis ad...@subcide.com wrote: On 28/04/2010, at 7:43 PM, Tab Atkins Jr. wrote: On Wed, Apr 28, 2010 at 4:31 AM, Ingo Chao i4c...@googlemail.com wrote: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. I think this may be a little vague/broad. I understand the intention, but say for example I have a logo image in the top left of my header, and my header doesn't have a static height set (in case something in the header needs it to grow or shrink for instance), then the height of the logo image is dictating the height of its parent, and this would seem to me, to be using an img as a layout tool, in a sense. Don't overthink it. It's a very simple rule. ^_^ Having an img *interact* in the layout is both fine and obviously necessary. The restriction is to prevent someone from using an img element *solely* for layout purposes. ~TJ I agree that using an img that spans up an area to show a fragment of a background-image is a hack, non-conforming with HTML5. Thanks for the answers. We are combining a hundred icons into one sprite for performance reasons, and it is not that easy to mask out portions of a background-image with pure CSS in every case. Tricky, or hackish. Maybe CSS3 will allow fragment indentifiers to slice a background image; a less hackish solution for the usage of sprites. http://www.w3.org/TR/css3-images/#url Thanks, Ingo -- Ingo Chao http://www.satzansatz.de/
Re: [whatwg] Directory upload via input type=file directory
fwiw, some platforms don't intend to support exposing folders to users at all...
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Wed, Apr 28, 2010 at 2:12 AM, James Graham jgra...@opera.com wrote: On 04/28/2010 10:27 AM, David Bruant wrote: When I started this thread, my point was to define a normalized way (through ECMAScript binding) to add array extras to array-like objects in the scope of HTML5 (HTMLCollection and inheriting interfaces). I don't see any reason yet to try to find a solution to problems that are in current web browsers. Of course, if/when a proposal emerges from this thread and some user agent accept to implement it, a workaround (probably, feature detection) will have to be found to use the feature in user agents that implement it and doing something equivalent in web browsers that don't. To be clear the proposals in this thread are pure syntactic sugar; they don't allow you do do anything that you can't already do like: Array.prototype.whatever.call(html_collection, arg1, arg2, ...) where whatever is the array method you are interested in. - and from that you can expect errors in Internet Explorer up to and including version 8. Of course there is nothing wrong with making the syntax more natural if it can be done in a suitably web-compatible way. However it seems more sensible to do this at a lower level e.g. as part of Web DOM Core. Sadly that spec is in need of an editor. The problem that has been well established is that Internet Explorer's implementation of host object collections or dhtml collection[1] objects is incompatible with JScript implementation of Array generics. The result of attempting to supply an Internet Explorer dhtml collection to an Array generic method, e.g. slice, as the `this` value, results in a jscript runtimer error: JScript object expected. IE8: [].slice.call(document.styleSheets); Result: Error: JScript object expected. No other 21st century browsers exhibit such problems, to my knowledge. The problem is with Internet Explorer. A program cannot safely use such constructs without at least feature testing with a try-catch. If Microsoft will release Internet Explorer 9 with dhtml collections implemented as native EcmaScript objects, then your proposal would not be needed and would only add more complexity to the overly complicated WebIDL (which should have been scrapped and restarted). The example would do what is obviously wanted of it and create an array from the StyleSheetList object. I am asking for Microsoft to not Internet Explorer 9 with dhtml collections as unwieldy error-throwing objects. I am asking Microsoft to instead release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects. Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? http://msdn.microsoft.com/en-us/library/ms533048%28VS.85%29.aspx
[whatwg] Headings and sections, role of H2-H6
I think the new section and heading model in HTML 5 is a welcome development. I've actually essentially been doing it that way for years -- eschewing H2-H6 and using DIV as a stand in for SECTION. I've always considered the H1-H6 concept a mess, and thankfully that seems to have been recognized by the people working on this spec. My understanding is that in HTML 5 the following is acceptable, and at least as acceptable as the alternative: use just H1, in conjunction with SECTION; forego use of H2-H6 for the most part; and, allow heading level to be determined by section nesting level. Is that correct? My question is about the explanation and code sample in the HTML 5 Working Draft section [4.4.11 Headings and sections]: Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level There are 2 code examples shortly after that passage, and the following one is indicated as being preferable to the other one because the sections are explicitly marked up instead of implied: body h1Apples/h1 pApples are fruit./p section h2Taste/h2 pThey taste lovely./p section h3Sweet/h3 pRed apples are sweeter than green ones./p /section /section section h2Color/h2 pApples come in various colors./p /section /body My point is that the passage makes it seem like using H1 throughout vs. using elements of the appropriate rank for the section's nesting level are equally sound and encouraged, and the code sample uses H2 and H3. I see why H2-H6 are retained for certain uses, but -- except in an HGROUP -- there's no good reason to use H2-H6 when writing new code with explicitly marked-up sections, is there? In that scenario isn't using just H1 throughout decidedly preferable to using H2-H6? And if so, then as long as authors are being strongly encouraged to mark up headings a certain way, wouldn't it be ideal to state a clear preference for using H1 throughout and include a third code example, indicated as the ideal: body h1Apples/h1 pApples are fruit./p section h1Taste/h1 pThey taste lovely./p section h1Sweet/h1 pRed apples are sweeter than green ones./p /section /section section h1Color/h1 pApples come in various colors./p /section /body
