Re: [whatwg] Directory upload via input type=file directory
On 28 Apr 2010, at 22:08, timeless wrote: fwiw, some platforms don't intend to support exposing folders to users at all... But they often have a similar concept anyway - the iPhone for example might let the user select an album of images to upload rather than a folder. __ Adrian Sutton, CTO UK: +44 1 628 353 032 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Directory upload via input type=file directory
Adrian wrote: But they often have a similar concept anyway - the iPhone for example might let the user select an album of images to upload rather than a folder. The platforms I have in mind doesn't seem to have such a concept at all.
Re: [whatwg] Headings and sections, role of H2-H6
On 04/29/2010 01:47 AM, Jesse McCarthy wrote: 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? Support for legacy clients (e.g. current AT) that has not been updated to understand the HTML5 outline algorithm.
Re: [whatwg] Headings and sections, role of H2-H6
On Thu, 29 Apr 2010 01:47:56 +0200, Jesse McCarthy whatwg-2010...@jessemccarthy.net wrote: 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. FWIW, I asked TimBL about this a decade ago, and he effectively agreed with you. The reason then was the same as now - backward compatibility (in that case with an SGML dialect that was in relatively wide use, which had the structure that got adopted into HTML). The ISO dialect of HTML more or less adopts the style in the example you quote, wrapping each logical section and its header in a div. But it requires the use of heading levels. 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? It appears to be. HTML5 defines an outline algorithm, whereas in HTML4 none is actually formally defined, so you can use headings in whatever level you see fit - although they are commonly used as markers to define an outline/table of contents. 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? Backwards compatibility - browsers, authoring tools, screen-scraping tools that syndicate content, User Style Sheets to improve readability, Assistive technologies, are all built today on the basis that different levels of headings imply sectioning and subsectioning, whereas almost no tools currently implement the new model. It is true that the old model isn't ideal, especially for documents so large and complex that they have more than half a dozen levels of content. But up to that arbitrary limit, the current approach more or less works in practice. It would be trivial to extend it to 9 levels by adding more elements, and people could be expected to understand how that works and upgrade their tools without re-implementing the algorithms. Going further would require them to pick the difference between one- and two-digit numbers, and the Web shows that (surprisingly) this is often too hard for coders to get right, so there would be some period of brokenness still. My conclusion is that the old model might just be a better bet for continuing - on the basis that it is good enough (we can define the algorithm that people already implement as easily as defining the section algorithm) and the cost of the change might not be worth the benefit it is expected to bring. 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: ... IMHO, of course cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On 28/04/10 23:28, Garrett Smith wrote: On Wed, Apr 28, 2010 at 2:12 AM, James Grahamjgra...@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. Adding a toArray operation (for example) won't work in IE up to and including version 8 though either. There's no point in adding a toArray operation for the pure reason that they currently don't implement another part of the spec (through the WebIDL references) currently. toArray adds no extra usefulness once they implement other parts of the spec. 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. In IE8 document.styleSheets.toArray().slice(0, 1); also throws an error. How does adding toArray help for IE8, which you're giving as the reason for adding it? Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? As far as I am aware, none of them are on this list. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Headings and sections, role of H2-H6
On Thu, Apr 29, 2010 at 2:47 AM, Adrian Sutton adrian.sut...@ephox.com wrote: This is certainly true, but it lends support for both the old and the new models working in tandem. Essentially there are two key use-cases for content management systems: 1. Authors being able to easily create content items. As you note above, h1-h6 makes far more sense to authors than invisible section elements and are far easier to apply correctly. Essentially content authors expect things to work roughly like Microsoft Word which the old model of headings does and so they generally get it right (especially if you disable the ability to add inline font size styles so they can't build a heading look-a-like manually). 2. The CMS needs to be able to assemble various content items in fairly arbitrary ways but still get a sensible heading structure in the result. The section element and the new heading model is an ideal solution for this case. A planet aggregator is a good example of this in action - each blog post is an entity to itself so would use headings starting at H1, but when aggregated the headings should start at H2 (or 3 or 4 depending on what else is on the aggregated page). So the blog author writes the post using H1-H6 because it's easy (or section if they prefer) and the aggregator simply wraps each blog post in a section so the resulting heading structure still works. Correct, the aggregation use-case was one of the big reasons for the heading-level scoping. As I understand it, while the spec recommends using only H1 if you're using sections, it's still valid and well defined to use h1-h6 along with section. Exactly. I certainly use both - sections starting at h1 within the page template, and h1-h6 in page content, because the former is nesting-agnostic, but the latter is easy to generate with Markdown. ~TJ
[whatwg] [canvas] getContext multiple contexts
Hey folks, A while ago questions came up in the WebGL WG about using a canvas with multiple rendering contexts, and synchronization issues that arise there. Here's our suggested change to getContext. It essentially allows for multiple contexts but adds no synchronization primitives other than the requirement that rendering must be visible to all contexts (that is, that they're rendered to the same destination space). This also adds the 'attributes' parameter which can customize the context that's created, as defined by the context itself. WebGL has its own context attributes object, and I'd suggest that the 2D context gain at least an attribute to specify whether the context should be opaque or not; but that's a separate suggestion from the below text. - Vlad object getContext(in DOMString contextId, in optional any attributes) A canvas may be rendered to using one or more contexts, each named by a string context ID. For each canvas, there is a set of zero or more active contexts. The getContext() method is used to obtain a particular rendering context for the canvas. 'contextId' must be a string naming a canvas rendering context to be returned. For example, this specification defines the '2d' context, which, if requested, will return either a reference to an object implementing CanvasRenderingContext2D or null, if a 2D context cannot be created at this time. Other specifications may define their own contexts, which would return different objects. The optional 'attributes' parameter must be either unspecified or an object specific to the context being requested. An unspecified value indicates a default set of attributes, as defined by the context ID. Unknown attributes must be ignored by the context. If getContext() is called with a context ID that the implementation does not support, it must return null. If there are no active contexts for the canvas, the implementation must create the specified context for the canvas. If a context ID that is already an active context for the canvas is requested, then any passed attributes must be ignored, and a reference to the existing context object must be returned. If there are one or more active contexts and a context ID that is not currently active is requested, it is up to the implementation to determine whether the requested context can be used simultaneously with all currently active canvas contexts. If simultaneous rendering with the requested context is not possible, getContext() must return null. Otherwise the implementation must create the specified context for the canvas. Certain context types may not support all combinations of context-specific attributes. If an unsupported set of attributes is requested during context creation, but the context ID is otherwise compatible with all existing contexts, then the implementation must create the new context with a set of attributes that best satisfies those requested. The caller is responsible for using context-specific APIs to determine whether the attributes used to create the context satisfy the requirements of the caller's code. If a new context is successfully created, a reference to an object implementing the context API is returned and the new context is added to the list of active contexts for the canvas. If multiple rendering contexts are active, they all render to the same canvas bitmap; they are not layered or otherwise isolated. Changes made to the canvas bitmap with one context must be immediately visible to any other active contexts on the canvas. The implementation must manage synchronization issues associated with rendering with different contexts to the same canvas. Supporting different rendering contexts within the same canvas is not recommended due to the significant cost of synchronization. Instead, each context API is encouraged to support generic interoperability with other canvases. For example, the 2D canvas API provides a drawImage method that can render the contents of another canvas.
[whatwg] Should default styles for h1-h6 match the outlining algorithm?
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections defines an outlining algorithm that gives each heading an outline depth that doesn't necessarily match its h1-h6 number (at least as I understand it, although I admit I haven't read the details). There's been a bit of discussion at various times on www-style and in other places about adding selectors that would allow CSS to match on HTML's outline depth. However, I was somewhat surprised to see that the rendering section http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#fonts-and-colors suggests default styles for h1-h6 that don't reflect the outline depth at all. Should it? Is the design of the outline algorithm in HTML5 intended to result in better default styles for headings? Or is it expected that the default styles are generally wrong but that CSS provides selectors that let authors easily improve them? (Why?) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)
On Thu, Apr 29, 2010 at 6:59 AM, Geoffrey Sneddon gsned...@opera.com wrote: On 28/04/10 23:28, Garrett Smith wrote: On Wed, Apr 28, 2010 at 2:12 AM, James Grahamjgra...@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. Adding a toArray operation (for example) won't work in IE up to and including version 8 though either. There's no point in adding a toArray operation for the pure reason that they currently don't implement another part of the spec (through the WebIDL references) currently. toArray adds no extra usefulness once they implement other parts of the spec. It's pretty hard to make out what you're getting at here. You the spec to refer to something here that they don't implement. It was also hard to understand your meaning in: | 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, ...) Array.prototype.slice.call(html_collection) is not something that one cannot already do; it *is* something that can be done, however one cannot expect an Array to be returned from that operation in IE = 8. Whatever it is you meant to convey in that paragraph was lost. If IE dhtml collections are implemented as native ECMAScript objects in IE9, the case for the toArray proposal is weak. The fact that IE implements dhtml collections as unwieldy error-throwing objects poses an obstacle at a fundamental level. That problem needs to be addressed by Microsoft. [...] In IE8 document.styleSheets.toArray().slice(0, 1); also throws an error. How does adding toArray help for IE8, which you're giving as the reason for adding it? What lead you to the assumption that I proposed toArray to address problems in IE8? I would not publish something so ludicrous. Travis Leithead and IE Team: Can you release Internet Explorer 9 with all dhtml collections implemented as native EcmaScript objects? As far as I am aware, none of them are on this list. He subscribes to the w3c-censored lists (dog-and-pony shows), but now that you mention it, I don't see his name showing up here much.
Re: [whatwg] Headings and sections, role of H2-H6
On Thu, Apr 29, 2010 at 5:34 AM, Steve Dennis ad...@subcide.com wrote: The other thing to take into consideration is Content Management Systems. The section model, while technically a much better document model, will be much much harder for things such as rich text editors to implement I would imagine. Due to sections often being visually invisible, the nesting of invisible elements can get unmanageable and broken very easily if clients with little understanding of the document model (probably 99% of them) are editing their own content via WYSIWYG a lot. The non-nested system of the h1 - h6 is much easier due to being single tags with no nesting, and every element being visually distinct. Yeah, inserting synthetic sections into arbitrary user-submitted content (WYSIWYG or not) is more or less impossible to do reliably. This was suggested for MediaWiki https://bugzilla.wikimedia.org/show_bug.cgi?id=6104, but you can't do it. Consider something like (adapted from the bug report) h1Widget Sales by Year/h1 table tr colspan=2th h2Widget Sales for 2006/h2 trthMonththNumber ... /table It's not even allowed to insert a section in the right place here, actually, so this particular example goes beyond automation problems. IMO, it's not reasonable to suggest that it's inappropriate to put headings in tables -- you could have a very long table and want its sections to show up in your table of contents. But you can't use any sectioning elements here.
