Re: [whatwg] The div element
Tab Atkins Jr. wrote (with snippage): In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. That doesn't sound correct to me. If they were all the same we could drop h1 to h6 and just use h. Section 3.8.6 states: These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank. Regards, Dave
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] wrote (with snippage): * 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 was confused by the name of the dialog element in exactly the same way you were, originally thinking it was to do with pop-up dialogue boxes. The HTML 4 spec states: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. ... which I presume influenced the addition of this element. If there is a lot of dialogue marked up on the Web it deserves its own element, if not I guess DL could be considered to stand for dialogue list in addition to definition list. * 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). I'm not entirely sure I understand, but if you want to further define the semantics of an element or make it more specialised, another group has put forward the idea of a role attribute http://www.w3.org/TR/2007/WD-xhtml-role-20071004/. Regards, Dave
Re: [whatwg] The div element
Geoff Pack wrote: Why does the HTML5 spec say The div element represents nothing at all ? [http://www.whatwg.org/specs/web-apps/current-work/#the-div] snip Personally I'd describe it more along the lines of: The div element is a generic way of representing document structure, but offers no further semantics. Where appropriate, elements with more specific meanings (such as section or aside) should be used instead. Use of the div element may be appropriate for extended features not covered by this specification, for example a new type of user interface control. Regards, Dave
[whatwg] ARIA (was: Re: Thoughts on HTML 5)
[EMAIL PROTECTED] wrote: snip As for my suggestion of reldata, my intent is to use the attribute for any type of data related to the element. The role attribute is intended to be used (from my understanding) to designate what role the element is playing on the page. This is not an appropriate place to put extra data that isn't necessary for the rendering or understanding of the element. My thought is doing something like this: div id=whatever reldata={clicks:1,track:true} The data format could be whatever someone wants, plain text, structured text, JSON...whatever you need. The point is to have a common place to dump extra but related data that isn't important to the understanding of the element. I often use custom attributes for this now, but it would be nice to have an official attribute for this purpose. It sounds like the two attributes would be complementary, with role defining the tag as a whateverwidget, and reldata describing the initial state and properties of the widget. I don't know if you've seen the recent Accessible Rich Internet Applications http://www.w3.org/TR/wai-aria/ draft? (There's also a primer at http://www.w3.org/TR/wai-aria-primer/.) It describes a number of standard states that can be added to custom controls. Rather than potentially fitting multiple values into a reldata attribute, it defines a host of attributes beginning with aria-. Example: span role=checkbox aria-checked=trueFoo/span I believe a number of script libraries (Dojo for example) plan on supporting ARIA. Firefox has some ARIA support already. The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Regards, Dave
[whatwg] HTML 5: Wording of license link type is too narrow
Hello, The scope of the license link type in section 4.12.3 seems too narrow to me. It's presently described like this: Indicates that the current document is covered by the copyright license described by the referenced document. I think the word copyright should be removed, allowing other types of intellectual property licence to be specified as well. As a use case, take for example a piece of documentation that is Apache-licensed: pThis piece of useful documentation may be used under the terms of the a rel=license ref=http://www.apache.org/licenses/LICENSE-2.0;Apache License, Version 2.0/a. Please note that Example#8482; is a trademark of Example.com Enterprises./p The license link not only refers to copyright law, but also trademark law and patent law. On a related note, should the copyright keyword really be a synonym for license? They seem to have distinct purposes to me: meta name=copyright content=Copyright 2009-2010 Example.com Enterprises link rel=license href=http://www.apache.org/licenses/LICENSE-2.0; type=text/html Thank you, Dave
[whatwg] RFC 4329 Scripting Media Types
Hi, Should Web Applications 1.0 make some kind of reference to RFC 4329? It defines the application/ecmascript and application/javascript media types; it also defines text/javascript and text/ecmascript but marks them as obsolete. http://www.ietf.org/rfc/rfc4329.txt I would suggest referring to it but noting that text/javascript and text/javascript;e4x=1 may be preferable for compatibility with current user agents. Thanks, Dave