[whatwg] Is main now an official HTML5 element?
Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yang
Re: [whatwg] Is main now an official HTML5 element?
Hi Steve, Thanks. And sorry, but til now I still don't understand the differences between whatwg and html wg. Could you please explain? Regards, Ian On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, I cannot speak for whatwg, but from the W3C HTML spec side the main element is in the HTML 5.1 spec and has been implemented in browsers and so will be added to HTML5 spec at some point as it likely meets the CR exit criteria. as for it being a sectioning element, there is currently an open bug on that, which we be dealt with. If you want to discuss the specification of the main element in HTML 5.1 specification feel free mail the html wg list. If you want to discuss definition as per the whatwg spec this is the place, although I will obviously follow ant discussions with interest regards SteveF Date: Wed, 13 Feb 2013 18:31:32 +0800 From: Ian Yang i...@invigoreight.com To: whatwg wha...@whatwg.org Subject: [whatwg] Is main now an official HTML5 element? Message-ID: CABr1FsfcaX8=B8TReG8Sz36W= h1w0hRY61+LG=cebo-zuwy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yan
Re: [whatwg] Is main now an official HTML5 element?
Hi Aurelio, I see. So whatwg mainly focus on the development of HTML and APIs needed for web applications. Thank you very much. Kind Regards, Ian On Thu, Feb 14, 2013 at 8:31 AM, Aurelio De Rosa aurelioder...@gmail.comwrote: I think this should answer your question: http://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F Best regards 2013/2/14 Ian Yang i...@invigoreight.com Hi Steve, Thanks. And sorry, but til now I still don't understand the differences between whatwg and html wg. Could you please explain? Regards, Ian On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, I cannot speak for whatwg, but from the W3C HTML spec side the main element is in the HTML 5.1 spec and has been implemented in browsers and so will be added to HTML5 spec at some point as it likely meets the CR exit criteria. as for it being a sectioning element, there is currently an open bug on that, which we be dealt with. If you want to discuss the specification of the main element in HTML 5.1 specification feel free mail the html wg list. If you want to discuss definition as per the whatwg spec this is the place, although I will obviously follow ant discussions with interest regards SteveF Date: Wed, 13 Feb 2013 18:31:32 +0800 From: Ian Yang i...@invigoreight.com To: whatwg wha...@whatwg.org Subject: [whatwg] Is main now an official HTML5 element? Message-ID: CABr1FsfcaX8=B8TReG8Sz36W= h1w0hRY61+LG=cebo-zuwy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yan -- Aurelio De Rosa email: aurelioder...@gmail.com email: a.der...@audero.it website: www.audero.it user group: ug.audero.it
Re: [whatwg] Is main now an official HTML5 element?
On Thu, Feb 14, 2013 at 1:06 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Feb 2013, Ian Yang wrote: I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? main is currently in the HTML standard. That doesn't mean much, though. What means something is that main is now implemented by two browsers in their development builds. Once they ship in final versions, that's the point at which we know that the feature is part of the platform. However, in spec, it still says that main element is not a sectioning element. Correct. Broadly speaking, sectioning elements are those with headings; main doesn't typically have a heading, it contains the content after the heading, distinguishing it from the content that is merely heading and navigation and so forth. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. I'm not sure what you mean here. The main content doesn't appear in the outline; the outline only contains the headers, essentially. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? There's already corresponding sectioning elements to indicate something that is main content -- article or section, depending on what exactly the content is. The spec goes into some detail about this, including with examples, here: http://whatwg.org/html#the-main-part-of-the-content http://whatwg.org/html#the-main-element http://whatwg.org/html#usage-summary-0 http://whatwg.org/html#sample-outlines Thanks Hickson for providing information, especially those example links. In the past, I always regarded a sectioning main content area is an indispensable part in a document. Today, information above tell me that the main content area seem doesn't need to be a titled section. So it seems that the following markup contains one unnecessary section and one unnecessary h1, and they cause one unnecessary indent in document outline. !DOCTYPE html titlelorem ipsum/title header h1Branding/h1 nav h1Navigation/h1 lorem ipsum /nav /header section id=main role=main h1Main Content/h1 section h1Welcome/h1 lorem ipsum /section section h1Intro/h1 lorem ipsum /section aside id=comp role=complementary h1Complementary Content/h1 article h1Latest News/h1 lorem ipsum /article article h1Recent Comments/h1 lorem ipsum /article /aside /section footer lorem ipsum /footer 1. Branding 1. Navigation 2. Main Content 1. Welcome 2. Intro 3. Complementary Content 1. Latest News 2. Recent Comments And the following markup and document outline are more appropriate. Since the main is not a sectioning element, now it only serves as an element for keyboard navigation (id=main) and for assistive technology to quick navigate to (role=main). !DOCTYPE html titlelorem ipsum/title header h1Branding/h1 nav h1Navigation/h1 lorem ipsum /nav /header main id=main role=main section h1Welcome/h1 lorem ipsum /section section h1Intro/h1 lorem ipsum /section aside id=comp role=complementary h1Complementary Content/h1 article h1Latest News/h1 lorem ipsum /article article h1Recent Comments/h1 lorem ipsum /article /aside /main footer lorem ipsum /footer 1. Branding 1. Navigation 2. Welcome 3. Intro 4. Complementary Content 1. Latest News 2. Recent Comments If any of my above understanding is flawed, please point it out for me. Thank you all. Sincerely, Ian Yang
Re: [whatwg] Is main now an official HTML5 element?
Sorry, maybe the markup structure still needs some modifications. One thing needs to be figured out is that should aside role=complementary be contained within main role=main? Or rather, is aside role=complementary a supporting content for the entire document or just for main role=main? If it is the latter, then aside is fine being within main. The spec doesn't look like it has clearly defined the relationship between main and aside. Any opinion will be appreciated. Thanks. Kind Regards, Ian Yang
Re: [whatwg] Is main now an official HTML5 element?
On Thu, Feb 14, 2013 at 12:37 PM, Charles McCathie Nevile cha...@yandex-team.ru wrote: Hi Ian, On Thu, 14 Feb 2013 01:31:36 +0100, Aurelio De Rosa aurelioder...@gmail.com wrote: I think this should answer your question: http://wiki.whatwg.org/wiki/**FAQ#What_is_the_WHATWG.3Fhttp://wiki.whatwg.org/wiki/FAQ#What_is_the_WHATWG.3F It doesn't seem to provide much useful information on the differences. According to its charter http://www.whatwg.org/charter**, WHAT-WG is a group of 9 individuals who work with a very simple set of rules (basically the editor of a specification decides what should be in it, but the 9 people can decide other things by overwhelming majority). There is a mailing list, IRC, etc, and everyone else who contributes to the discussion is called a contributor. More about how WHAT-WG works is described at http://wiki.whatwg.org/wiki/* *FAQ http://wiki.whatwg.org/wiki/FAQ The HTML WG is one of the working groups of W3C. The working group has a charter that describes some of how it works: http://www.w3.org/2007/03/** HTML-WG-charter http://www.w3.org/2007/03/HTML-WG-charter W3C itself is a consortium of member organisations, and the links from the HTML WG charter to the process document will lead you into more information about how W3C works. Note that in my personal opinion the Wikipedia page about W3C is outdated and very poor quality information. cheers Chaals Hi Charles, Thank you for providing resources. I will try to determine what topic belongs to which group in the future. Kind Regards, Ian Best regards 2013/2/14 Ian Yang i...@invigoreight.com Hi Steve, Thanks. And sorry, but til now I still don't understand the differences between whatwg and html wg. Could you please explain? Regards, Ian On Thu, Feb 14, 2013 at 12:59 AM, Steve Faulkner faulkner.st...@gmail.com**wrote: Hi Ian, I cannot speak for whatwg, but from the W3C HTML spec side the main element is in the HTML 5.1 spec and has been implemented in browsers and so will be added to HTML5 spec at some point as it likely meets the CR exit criteria. as for it being a sectioning element, there is currently an open bug on that, which we be dealt with. If you want to discuss the specification of the main element in HTML 5.1 specification feel free mail the html wg list. If you want to discuss definition as per the whatwg spec this is the place, although I will obviously follow ant discussions with interest regards SteveF Date: Wed, 13 Feb 2013 18:31:32 +0800 From: Ian Yang i...@invigoreight.com To: whatwg wha...@whatwg.org Subject: [whatwg] Is main now an official HTML5 element? Message-ID: CABr1FsfcaX8=B8TReG8Sz36W= h1w0hRY61+LG=Cebo-ZUWYfqA@**mail.gmail.comcebo-zuwy...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi editors and all other folks, I saw the SitePoint article Introducing the New HTML5 main Elementhttp://www.sitepoint.**com/html5-main-element/http://www.sitepoint.com/html5-main-element/ yesterday. Does that mean main element has been approved by all editors of the working group? However, in spec, it still says that main element is not a sectioning element. That means, in document outline, main content will form another tree structure instead of appearing under the original website tree structure. Can we have somebody advise on this? Is there a special consideration to not making main a sectioning element? Sincerely, Ian Yan -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [whatwg] Is main now an official HTML5 element?
Hi Hickson, Thanks for the help. There is one thing which makes me confused. You mentioned the main is mainly serves as a styling hook. If what we need is just a styling hook, why was main introduced? We could just use div. So iiuic, the main still has its purpose because it natively has the role main. Please correct me if I'm wrong. Kind Regards, Ian Yang
Re: [whatwg] use cases for untitled article and section elements
On Tue, Jan 15, 2013 at 8:05 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: 2013-01-15 11:57, Steve Faulkner wrote: Can anyone point me to or provide use cases for untitled article and section elements? The example that first comes into my mind is a discussion forum where contributions (which would appear to match the article idea) can be posted, and are usually posted, without a title of any kind. A discussion has a title (subject), but individual contributions are basically just text, though in advanced systems they may contain markup. Me, too. The one came into my mind is blog comments, which are often coded using untitled articles. But personally I think that is wrong because every sectioning element should have a heading. Regards, Ian Yang
Re: [whatwg] use cases for untitled article and section elements
On Tue, Jan 15, 2013 at 8:33 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote: 2013-01-15 14:15, Ian Yang wrote: The one came into my mind is blog comments, which are often coded using untitled articles. But personally I think that is wrong because every sectioning element should have a heading. Using headings is generally a very good authoring principle, but there are exceptions. Small comments rarely benefit from titles (headings). A very different example is a novel. A novel is almost always divided into sections, and sections may have subsections (visually separated e.g. using extra empty space or maybe ***). The sections may or may not have title. Often they have just numbers, presented as titles like Chapter 1, so they are more or less pseudo-titles (and could be replaced by CSS-generated content). Subsections almost never have headings. So what a browser could do, with a novel that uses section, is to provide an outline of the structure, possibly so that along with numbers, there are short excerpts from the start of each section or subsection. Yucca Imho, there is a reason for each sectioning element to have a heading. If a content doesn't need a heading, then it should not be coded using sectioning element. Because blog comments are coded using articles, at least their author names should be contained within h1s so that in the document outline they are presented clearly. For example, h1Mike Smith says/h1, or h1Commenter: Mike Smith/h1, or just h1Mike Smith/h1. Every section of a novel needs a heading, too. Otherwise in the document outline we will see a bunch of Untitled Sections. Kind Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main, and main element parsing behaviour
Hi Steve, Thanks for the info. I had sent it to public-html-comme...@w3.org and had added new info to Bugzilla. Regards, Ian Yang On Sat, Dec 22, 2012 at 7:20 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, in regards to your post about how main is defined: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0239.html the main element [2] is being standardised at the w3c not the whatwg and as such, the whatwg list moderator has requested that discussion not continue on this list unless new information is provided that will result in a change of his opinion. comments on the spec should be directed as per below: The main element spec is published by the HTML Working Grouphttp://www.w3.org/html/wg/as a Working Draft. If you are not a HTML working group member and wish to make comments regarding this document please send them to public-html-comme...@w3.org (subscribepublic-html-comments-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html-comments/). If you are a HTML working group member and wish to make comments regarding this document, please send them to public-h...@w3.org (subscribepublic-html-requ...@w3.org?subject=subscribe, archives http://lists.w3.org/Archives/Public/public-html/). All feedback is welcome. Anyone can also file a bug against the spec, as you have in this regard [1], so please add new info there. I will respond to any bugs or comments in due course. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591 [2] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html -- with regards Steve Faulkner
Re: [whatwg] Use of article to identify the main content of a web page
On Tue, Nov 20, 2012 at 2:08 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 19 Nov 2012, Ian Yang wrote: On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Nov 2012, Ian Yang wrote: That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. That's called article. Thanks Hickson. Actually I had turned down my own opinion ( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html ). And isn't article used to wrap an entire blog post? Like this: article header / div / footer / /article Right. It wraps all the elements of a blog post. All the ps, uls, ols, figures, tables, h1s, footers, etc. If you just want to wrap a subpart of that for rendering purposes, div is the element you want. Basically div is always the answer if the question is how do I provide myself a hook for CSS styling. A hook for CSS styling is just a side benefit. That's not the primary thing I want. Personally I care about the meaningfulness and the semantic aspect of HTML. Therefore what I want is a meaningful element which is designed to wrap the content of a blog post. Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main
On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 15 Nov 2012, Ian Yang wrote: That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. That's called article. Thanks Hickson. Actually I had turned down my own opinion ( http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html ). And isn't article used to wrap an entire blog post? Like this: article header / div / footer / /article Are you suggesting that we code it like the following one? article header / article / footer / /article Regards, Ian Yang
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett ...@gmail.com wrote: Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post.
Re: [whatwg] A plea to Hixie to adopt main
On Thu, Nov 15, 2012 at 7:27 PM, Ian Yang i...@invigoreight.com wrote: On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett ...@gmail.com wrote: Personally, I'd rather see main be more about marking up content in general, such as in this example which is invalid given the current state of the spec: article id=1 header / main / footer / /article article id=2 header / main / footer / /article ...although this would probably fit better as a content element, and would require a whole other line of discussion that can wait for another day. ☺ That's a good idea. We really need an element to wrap all the ps, uls, ols, figures, tables ... etc of a blog post. I'm sorry, but I have to eat my above words. Previously I proposed that main being a sectioning element for a better document outline ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591#c0). So the use of mains in all blog posts won't help improving the document outline. Regards, Ian Yang
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Steve, Thanks for your work, too :) Regards, Ian On Thu, Oct 18, 2012 at 2:14 PM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Thanks for the detailed example, your reasoning is clear now and that gives me something to work with, and thanks for filing a bug! will respond on bug. regards SteveF
Re: [whatwg] maincontent element spec updated and supporting data provided
On Thu, Oct 18, 2012 at 1:31 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Ian, Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? I have responded on the HTML WG list to a similar naming preference comment: http://lists.w3.org/Archives/Public/public-html/2012Oct/0112.html Thank you. Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Can you provide some more reasoning for making the element sectioning content? There is a now W3C bugzilla component for the HTML5 maincontent extension, you can file bugs against the spec there to ensure that your comments get recorded and responded to: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WGcomponent=maincontent%20element regards SteveF Because both being elements for content, it is inconsistent that complementary content is sectioning element and main content is not. Another reason is about document outline. Please take a look at the markup below: !DOCTYPE html titleblablabla/title header h1Branding/h1 nav h1Navigation/h1 blablabla /nav aside h1Search/h1 blablabla /aside /header main role=main h1Main Content/h1 section h1Welcome/h1 blablabla /section section h1Brief Intro/h1 blablabla /section /main aside role=complementary h1Complementary Content/h1 article h1Latest News/h1 blablabla /article article h1Recent Comments/h1 blablabla /article /aside footer blablabla /footer If the main content element is a sectioning element, the document outline formed by the above code will be clear and hierarchically correct: 1. Branding 1. Navigation 2. Search 3. Main Content 1. Welcome 2. Brief Intro 4. Complementary Content 1. Latest News 2. Recent Comments But if the the main content element is not a sectioning element, the document outline will be confusing and hierarchically incorrect: 1. Branding 1. Navigation 2. Search 2. Main Content 1. Welcome 2. Brief Intro 3. Complementary Content 1. Latest News 2. Recent Comments Both main content and complementary content are content, so they are supposed to be at the same level in document outline. A bug report for this issue has been filed on bugzilla. Kind Regards, Ian Yang
Re: [whatwg] maincontent element spec updated and supporting data provided
Hi Steve, Thanks for the great research effort on the main content element. Like the succinct and simple name of complementary content (aside), could we make the element name of the main content as succinct as aside? For instance, main? Since the complementary content (aside) is a sectioning element, could we make the main content element a sectioning element, too? Kind Regards, Ian Yang On Wed, Oct 17, 2012 at 8:03 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi all, I have updated the maincontent spec [1] and would appreciate any feedback (including, but not limited to implementers). In the process of developing the maincontent element spec [1] I looked at data from a number of sources [3] on frequency of usage of id values to indicate the main content area of a web page. I also used data [2] I gathered in April 2012 based on a URL list of the top 10,000 most popular web sites. In preparing the data [2] I subsetted the total usable HTML documents (approx 8900 pages - the home pages for sites in the top 10,000 URLs list ) by searching for the use of the HTML5 doctype (approx 1545 pages). I figured that documents using the HTML5 doctype would provide the freshest code. What is apparent from the home page data in the sample: * use of a descriptive id to value to identify the main content area of a web page is common. (id=main|id=content|id= maincontent|id=content-main|id=main-content used on 39% of the pages in the sample [2]) * There is a strong correlation between use of ARIA role='main' [5] on an element with id values of 'content' or 'main' or permutations. (when used = 101 pages) 77% were on an element with id values of 'content' or 'main' or permutations. * There is a strong correlation between use of id values of 'content' or 'main' or permutations as targets for 'skip to content'/'skip to main content' links (when used = 67 pages) 78% of skip link targets # were elements with id values of 'content' or 'main' or permutations. * There appears to be a strong correlation in the identification of content areas (with id values of 'content' or 'main' or permutations.) as what is described in the spec as appropriate content to be contained with a maincontent element [1]: The maincontent element representshttp://dev.w3.org/html5/spec/rendering.html#representsthe main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application. ... The main content section of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form). I have prepared approx 440 sample pages [4] from the same URL set with CSS to outline and identify use of container elements with id values of 'content' and/or 'main' and role=main, these samples can be used to visually assess how closely the spec definition of maincontent matches the reality of element usage with the stated id values. [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html [2] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ [3] http://triin.net/2006/06/12/CSS#figure-34, http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html, http://dev.opera.com/articles/view/mama-common-attributes/#id note: The first link in each list item links to the original page the second link prefixed with copy is the same page with the CSS added. [4] http://www.html5accessibility.com/tests/HTML5-main-content/ [5] http://www.w3.org/TR/wai-aria/roles#main -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Elements feedback
On Fri, Sep 28, 2012 at 2:27 AM, Ian Hickson i...@hixie.ch wrote On Mon, 16 Jul 2012, Ian Yang wrote: But your opinion does remind me of the small element. That element is a perfect example of introducing and using an element simply for its rendering. Unlike ul and ol, it's not meaningfully named at all. Honestly, I'm not a huge fan of recycling a deprecated element. If we need an element for side comments, we could introduce comment or c. If we need an element for document info, we could introduce info. That would make HTML elements more meaningfully named. The names are opaque -- most people who write HTML don't speak English as their first language, if at all, so we can't really rely on the element names to convey the semantics. We couldn't use comment, some browsers default to hiding comment elements. We could introduce c or info, but small has the advantage that it already renders in an appropriate way in legacy user agents. When it comes to conveying semantics, many existing HTML elements' name already have such an issue. So developers should at least have a basic understanding of English. After all, it's not hard to learn a few more English words. :-) The displaying of new elements like c or info could be fixed by using javascript like how we have fixed the displaying of header, footer, article, .. etc in legacy browsers. On Thu, 19 Jul 2012, Ian Yang wrote: Let's consider form we used often. When coding a form, none of us make it like the following one because that's obviously very ugly and, most importantly, it hurts our eyes! form method=post action=/ label for=nameName/label input id=name type=text label for=emailEmail/label input id=email type=email label for=siteWebsite/label input id=site type=url label for=phonePhone/label input id=phone type=tel input id=male type=radio label for=maleMale/label input id=female type=radio label for=femaleFemale/label label for=msgMessage/label textarea id=msg/textarea /form Instead, we use div (some people use p) to group sub elements to make them more organized, and we also get the side benefit of having more elements for styling: form method=post action=/ div label for=nameName/label input id=name type=text /div div label for=emailEmail/label input id=email type=email /div div label for=siteWebsite/label input id=site type=url /div div label for=phonePhone/label input id=phone type=tel /div div input id=male type=radio label for=maleMale/label /div div input id=female type=radio label for=femaleFemale/label /div div label for=msgMessage/label textarea id=msg/textarea /div /form Personally I'd recommend using structures like: plabelPhone input name=phone type=tel/label/p ...for each line, but the effect, and semantics, are the same. That structure is simple and elegant. Yet in some circumstances, that might cause styling issues. For example, developers might want to float the label text to right or slightly adjust its vertical aligning. And usually life cycle type contents are presented as circles. Without li(s), it will be hard to style them. This is something we should fix in CSS. Yes, we could do absolute positioning for every dt and dd, but that's troublesome. With the optional use of li, we only need to position lis. On Fri, 20 Jul 2012, Ian Yang wrote: li in dl is rendered without problems in IE6+, FF3.6+, Chrome, and Safari. Only in Opera that definition term and the bullet aren't at the same line. One big problem with li in dt/dd (beyond it not really being necessary) is that it doesn't parse well. /dt, /dd, and /li are optional, but when you use these elements together and omit those tags, markup like this: dl li dt... dd... li dt... dd... ...turns into DOMs like this: dl li dt... dd... li dt... dd... Furthermore, browsers need to be compliant with the standards, not the standers need to be compliant with browsers. If the latter were true, we wouldn't have had so many new HTML5 elements to use. We need to be compatible with the browsers. Adding new features is something we have to do very carefully to avoid not breaking the browsers. Since the proposed use of li is optional, developers who want to use it should include closing tags (/li, /dt, and /dd). That solves the issue. With regard to compatibility issue, we could always use javascript to fix that. It's like how we have fixed header, footer, article, .. etc. Kind Regards, Ian Yang
Re: [whatwg] content element, which we need in our documents
Hi Steve and all other chief editors, Thanks for drafting that. Comparing to the complementary element, maybe we could simply call this new element main. What's your thought? And could we make it a sectioning element instead of a flow content? The document outline can become more clearer if the main content element is a sectioning element. Please refer to a previous topic Document outline and the wrapper of the main content ( http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0157.html ) Kind Regards, Ian Yang On Mon, Sep 10, 2012 at 4:02 AM, Steve Faulkner faulkner.st...@gmail.comwrote: Hi Chaals, thanks for you counterpoints I have taken a stab at drafting a definition of a maincontent element: http://www.html5accessibility.com/tests/maincontent.html any feedback welcome! regards Stevef Message: 7 Date: Sun, 02 Sep 2012 15:05:58 +0200 From: Charles McCathie Nevile cha...@yandex-team.ru To: whatwg wha...@whatwg.org Subject: Re: [whatwg] content element, which we need in our documents Message-ID: op.wj0en8gmy3oazb@chaals.local Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes On Thu, 30 Aug 2012 20:10:15 +0200, Ian Hickson i...@hixie.ch wrote: ... On Fri, 29 Jun 2012, Cameron Jones wrote: If the content is a special section within the document you should use the section element which has semantic meaning over div. Alternatively you could use article if it's distinct and self-contained. These two elements serve to disambiguate the abstract idea of content into something with semantic meaning which can be instrumented by document consumers. Indeed, dependong on what exactly you mean by content these might be more appropriate. I had believed that the article element would fulfil the requirement. But the below suggests that my assumption may be incorrect... On Fri, 29 Jun 2012, Ian Yang wrote: As described in whatwg specs, a section, in this context, is a thematic grouping of content, typically with a heading. As for a article, which usually contains its own header and footer, is used to form an independent content like blog entry, comment, or application. Both section and article elements are not the candidate for containing a website or a blog entry's main content. That obviously is the reason that the example of the nav in HTML5 spec doesn't use them. The element that contains a website or a blog entry's main content is body, as far as I can tell. That is technically true, but not useful. The body element also contains a page's header, footer, general linking buttons (share/like/rate/...), navigation, advertising, tracking tokens, responses to the content, and more. On Fri, 29 Jun 2012, Aurelio De Rosa wrote: I agree with Ian about the use of article and section, the specifications are really clear on those elements. The are used to wrap an entire entry, not the content (in the meaning Ian stated). Well, the content is what is left after you take out the stuff that isn't the content (header, footer, etc). Yes. If we have elements for all such things, the logical conclusion is that we don't need one for the main content. In practice, this also supposes that authors use those elements. As far as I can tell, those asking for such an element do not believe we do have all the other elements, and/or are not convinced they for a sufficient proportion of cases they are going to be used as designed. To turn the question around, if it is more convenient for authors to identify the main content, and not think about the classification of other parts, should we offer that facility as part of the platform? Or does it make sense to say that only the exhaustive identification of all supplementary content is an appropriate way to mark up a page anyway? The read question for me is: What is the problem of having the content at the same level of header and footer (for example inside an article)? Can't we treat everything inside an article which is not in header or footer is the real content? That's the intent of the spec, right. In that case I think the spec is wrong. I suspect that real content will fail to match this intent in a significant proportion of cases. I also suspect that allowing authors to identify the main content would significantly alleviate the problems caused... On Fri, 29 Jun 2012, Ian Yang wrote: By analyzing the example in HTML5 spec, wrapping all content elements can make the structure of the document become more organized. After all, content elements all being at the same level of header and footer is unreasonable, and sometimes looks messy, especially when there are many different kinds of content elements (p, figure, pre, a, table, .. etc). I don't understand what the problem is here. How is it messy? If you just want to group some elements together
Re: [whatwg] Suggest making dt and dd valid in ol
On Wed, Aug 1, 2012 at 12:56 AM, Leif Halvard Silli
xn--mlform-...@xn--mlform-iua.no wrote:
Ian Yang on Thu, 19 Jul 2012 15:04:48 +0800, wrote:
From previous discussions, some people had suggested possible markup for
life cycle type contents. And personally I will stick to using dl
until
there is a better solution.
There is still one thing left unanswered. And that's whether we will be
able to put li inside dl.
Let's consider form we used often. When coding a form, none of us make
it
like the following one because that's obviously very ugly and, most
importantly, it hurts our eyes!
form method=post action=/
label for=nameName/label
input id=name type=text
[...]
Instead, we use div (some people use p) to group sub elements
[...]
form method=post action=/
div
label for=nameName/label
input id=name type=text
/div
Would it not be better if, rather than div, you used fieldset? Then
it would not only benefit your eyes but also the semantics:
fieldset
label for=nameName/label
input id=name type=text
/fieldset
If I remember correctly, fieldset is for grouping in complex and large
forms whose fields needs to be grouped into different categories. So it
might be improper to use it as dividers in simple and small forms.
There is even the option that you wrap the label around the input -
then you can drop the @id too - and be semantic as well:
labelName
input type=text
/label
This way you can 'increase' both the semantics and the 'eye wellness'.
I once was thinking about that idea, too, and I gave it up. I have to admit
that it was mainly because of styling reasons. Putting input inside
label can cause styling inconveniences in many situations.
But look at that structure, label is literally used for wrapping label
texts, so putting a input which is not label texts inside a label is
far-fetched and non-semantic, isn't it?
Like above examples, the following dl is not well organized, and it's
also a pain to read it:
dl
dtLorem Ipsum/dt
ddSit amet, consectetur adipiscing elit./dd
dtAliquam Viverra/dt
ddFringilla
[... etc ...]
/dl
If developers could, *optionally*, use li to wrap each group, the code
would be more organized:
dl
li
dtLorem Ipsum/dt
ddSit amet, consectetur adipiscing elit./dd
/li
li
dtAliquam Viverra/dt
ddFringilla nulla nunc enim nibh, commodo sed cursus in./dd
/li
[...]
/dl
And usually life cycle type contents are presented as circles. Without
li(s), it will be hard to style them.
How about the following method - essentially a variant of
ollidfnEgg/dfn: A white egg. [etc]/ol, as proposed by by Ian:
ollifigurefigcaptionLorem Ipsum/figcaption
Sit amet, consectetur adipiscing elit.
/figure/li
lifigurefigcaptionAliquam Viverra/figcaption
Fringilla nulla nunc enim nibh, commodo
sed cursus in./figure/li/ol
Or, if one wishes, one could drop the olli…/li/ol completely
and instead e.g. do the following:
stylefigure figure{display:list-item}/style/headbody
figure
figure
figcaptionLorem Ipsum/figcaption
Sit amet, consectetur adipiscing elit.
/figure
figure
figcaptionAliquam Viverra/figcaption
Fringilla nulla nunc enim nibh, commodo
sed cursus in.
/figure
/figure
They looks fancy. However, I have a feeling that a life cycle should be a
definition list, and the above examples don't possess the meaning
definition list. I'm not sure if I'm correct or not. Let me know if I'm
not.
And figure is used in contents which have context, typically articles or
blog posts, to illustrate its context. So it might not be an idea element
inside li.
Since the *optional *use of li in dl could solve many problems, may
we
have li being valid in dl?
The most serious problem with that proposal seems to me to be that the
li only have styling functionality. I think one would have to define
it as a new list type, where li has semantic meaning, and then it
could perhaps work.
--
Leif Halvard Silli
Excuse me, but I'm not sure if I understand you. li means list item.
That's very self-explanatory and semantic.
Sincerely,
Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
On Wed, Aug 1, 2012 at 9:26 AM, Ian Yang i...@invigoreight.com wrote:
Like above examples, the following dl is not well organized, and it's
also a pain to read it:
dl
dtLorem Ipsum/dt
ddSit amet, consectetur adipiscing elit./dd
dtAliquam Viverra/dt
ddFringilla
[... etc ...]
/dl
If developers could, *optionally*, use li to wrap each group, the code
would be more organized:
dl
li
dtLorem Ipsum/dt
ddSit amet, consectetur adipiscing elit./dd
/li
li
dtAliquam Viverra/dt
ddFringilla nulla nunc enim nibh, commodo sed cursus in./dd
/li
[...]
/dl
And usually life cycle type contents are presented as circles. Without
li(s), it will be hard to style them.
How about the following method - essentially a variant of
ollidfnEgg/dfn: A white egg. [etc]/ol, as proposed by by Ian:
ollifigurefigcaptionLorem Ipsum/figcaption
Sit amet, consectetur adipiscing elit.
/figure/li
lifigurefigcaptionAliquam Viverra/figcaption
Fringilla nulla nunc enim nibh, commodo
sed cursus in./figure/li/ol
Or, if one wishes, one could drop the olli…/li/ol completely
and instead e.g. do the following:
stylefigure figure{display:list-item}/style/headbody
figure
figure
figcaptionLorem Ipsum/figcaption
Sit amet, consectetur adipiscing elit.
/figure
figure
figcaptionAliquam Viverra/figcaption
Fringilla nulla nunc enim nibh, commodo
sed cursus in.
/figure
/figure
They looks fancy. However, I have a feeling that a life cycle should be
a definition list, and the above examples don't possess the meaning
definition list. I'm not sure if I'm correct or not. Let me know if I'm
not.
Sincerely,
Ian Yang
Sorry, after reconsideration, I think it's okay to use ol.
I was wrong to assume that all life cycles have definition term and
definition description pairs. After some googling, I found that some life
cycles have only terms and don't have descriptions.
So when there are only terms, it's okay to use:
ol
liEggli
liCaterpillarli
..
..
/ol
However, dfn examples I could found only use it in normal paragraphs. I'm
not sure if that's appropriate to put it in list items like
lidfnterm/dfn: blablabla/li. And besides, the unwanted colon can
causes styling inconveniences :-P
http://www.w3.org/wiki/HTML/Elements/dfn
http://reference.sitepoint.com/html/dfn
Sincerely,
Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
From previous discussions, some people had suggested possible markup for life cycle type contents. And personally I will stick to using dl until there is a better solution. There is still one thing left unanswered. And that's whether we will be able to put li inside dl. Let's consider form we used often. When coding a form, none of us make it like the following one because that's obviously very ugly and, most importantly, it hurts our eyes! form method=post action=/ label for=nameName/label input id=name type=text label for=emailEmail/label input id=email type=email label for=siteWebsite/label input id=site type=url label for=phonePhone/label input id=phone type=tel input id=male type=radio label for=maleMale/label input id=female type=radio label for=femaleFemale/label label for=msgMessage/label textarea id=msg/textarea /form Instead, we use div (some people use p) to group sub elements to make them more organized, and we also get the side benefit of having more elements for styling: form method=post action=/ div label for=nameName/label input id=name type=text /div div label for=emailEmail/label input id=email type=email /div div label for=siteWebsite/label input id=site type=url /div div label for=phonePhone/label input id=phone type=tel /div div input id=male type=radio label for=maleMale/label /div div input id=female type=radio label for=femaleFemale/label /div div label for=msgMessage/label textarea id=msg/textarea /div /form Like above examples, the following dl is not well organized, and it's also a pain to read it: dl dtLorem Ipsum/dt ddSit amet, consectetur adipiscing elit./dd dtAliquam Viverra/dt ddFringilla nulla nunc enim nibh, commodo sed cursus in./dd dtPretium Et Nibh/dt ddQuisque porttitor mauris ut velit tincidunt ut hendrerit erat mollis./dd ddA dui condimentum suscipit. Quisque tortor nulla./dd dtTempus Et Augue/dt ddVivamus ipsum massa, tristique tempus lobortis a./dd dtVivamus Semper Convallis/dt dtCras Eget Eros/dt ddPellentesque. Vestibulum volutpat mollis placerat./dd ddMaecenas eu tempus ut, imperdiet eu tortor./dd dtPellentesque/dt ddLobortis consequat ipsum id pulvinar./dd dtNibh Purus/dt ddAdipiscing sit amet ultrices quis, consequat eu dolor./dd /dl If developers could, *optionally*, use li to wrap each group, the code would be more organized: dl li dtLorem Ipsum/dt ddSit amet, consectetur adipiscing elit./dd /li li dtAliquam Viverra/dt ddFringilla nulla nunc enim nibh, commodo sed cursus in./dd /li li dtPretium Et Nibh/dt ddQuisque porttitor mauris ut velit tincidunt ut hendrerit erat mollis./dd ddA dui condimentum suscipit. Quisque tortor nulla./dd /li li dtTempus Et Augue/dt ddVivamus ipsum massa, tristique tempus lobortis a./dd /li li dtVivamus Semper Convallis/dt dtCras Eget Eros/dt ddPellentesque. Vestibulum volutpat mollis placerat./dd ddMaecenas eu tempus ut, imperdiet eu tortor./dd /li li dtPellentesque/dt ddLobortis consequat ipsum id pulvinar./dd /li li dtNibh Purus/dt ddAdipiscing sit amet ultrices quis, consequat eu dolor./dd /li /dl And usually life cycle type contents are presented as circles. Without li(s), it will be hard to style them. Since the *optional *use of li in dl could solve many problems, may we have li being valid in dl? Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
On Fri, Jul 20, 2012 at 2:02 AM, Alex Bishop alexbis...@gmail.com wrote: On 19/07/2012 08:04, Ian Yang wrote: Since the *optional *use of li in dl could solve many problems, may we have li being valid in dl? Probably not, as it has similar drawbacks as the proposed di element: http://wiki.whatwg.org/wiki/FAQ#HTML_should_group_.3Cdt.3Es_and_.3Cdd.3Es_together_in_.3Cdi.3Es.21 Thanks. However, the drawbacks mentioned in that document is about the nonexistent di, not the existent li. li in dl is rendered without problems in IE6+, FF3.6+, Chrome, and Safari. Only in Opera that definition term and the bullet aren't at the same line. Furthermore, browsers need to be compliant with the standards, not the standers need to be compliant with browsers. If the latter were true, we wouldn't have had so many new HTML5 elements to use. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/16 Ian Hickson i...@hixie.ch On Sat, 14 Jul 2012, Ian Yang wrote: Recently I was involved in a project. One of its pages has a special content which is like a life cycle. There are several stages in the cycle, each stage has a term followed by some text describing the term. Let's take the life cycle of butterfly for example: Egg A white egg. Caterpillar The egg hatches into a caterpillar. The caterpillar eats and grows a tremendous amount. Pupa The caterpillar forms a hard outer shell. Inside the shell, the caterpillar changes into a butterfly. Butterfly Butterflies live for only a short time. They will fly, mate, and reproduce. The female lays an egg that was fertilized by the male. By seeing such contents, we usually code it using definition list (dl). At first, I was thinking the same idea. But then I realized that stages in a life cycle should be regarded as ordered contents. So ordered list (ol) would be more appropriate. ol and dl would both be fine here. I'd probably go with ol, because it's a list of states, each of which has a name, rather than a list of names, but both are reasonable. With ol, I'd probably write: ol lidfnEgg/dfn: A white egg. lidfnCaterpillar/dfn: The egg hatches... ...and so on. Thanks. That use looks fine, yet I'm a bit confused now. What's the difference between *using definition list (dl)* and *using ordered list ( ol) with dfn inside of it*? And how could we determine when to use which? If we could make dt and dd being not restricted to dl only, but could also exist in ol, the problem will be solved perfectly. It's not clear that there's a problem to be solved. :-) (Also, there are parsing issues that make changing this area of the spec be rather fraught with peril.) Yeah, I had gave up that idea as it loses the meaning definition list. On Sat, 14 Jul 2012, Ian Yang wrote: Thanks for the info about the spec saying in dl the order of the list of groups *may* be significant. However, what it says means a dl itself is unable to tell whether its contents are unordered or ordered, and we have to judge that by ourselves. Well, what it means is that a user agent can't randomly reorder a dl's contents, as that would violate the rule that its rendering must faithfully represent the page's semantics. (The spec relies on this in several places to mark up English-prose equivalents of switch statements in its algorithms, for example.) Comparing to ul and ol which themselves are able to tell whether their contents are unordered and ordered, the dl itself being unable to do that is, imho, disappointing. It's something we could add, but it's not clear that there's a compelling need for it. What is the use case for knowing that a dl's contents can be arbitrarily reordered? Well, I'm not sure if user agent can't randomly reorder its contents equals to the order of its content is important. If it does, some use cases of dl such as FAQ may became incorrect as the order of contents of FAQ is usually unimportant. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/16 Jukka K. Korpela jkorp...@cs.tut.fi 2012-07-16 5:36, Ian Yang wrote: Imo, ul means the order of the items is unimportant, not browsers can render the items in any order. But if the order is unimportant, there still _is_ an order. Being unordered would be something else. The order you are referring to here is just the sequence of writing li(s) into the ul. That's not the actual meaning of the order of list items and is unimportant. And what would it matter to indicate the order as important if you only do that in markup, without affecting rendering, search engines, etc., at all? It's like invisible ink in a book. If it is somehow relevant to say that the order is unimportant, you have to, well, *say* it (in words). Because as a coder, my main concern is whether the meaning of the code I write is correct or not. If the order is unimportant, I write ul, and my job is done. As for default browser rendering, search engines, etc ... That's not my main concern. The only reason for this unordered list idea (a list is by definition unordered; a set, or a multiset, is not) is the willingness to keep ul and ol in HTML (it would be very impractical to omit one of them) without admitting that they were introduced, and are being used, simply for bulleted and numbered lists. So this resembles the confusing play with words regarding i and b. At first, maybe they were introduced and misused by some people because of their default renderings. They anyway possess meanings in their names. And nowadays they are used by their meanings instead of their default rendering. But your opinion does remind me of the small element. That element is a perfect example of introducing and using an element simply for its rendering. Unlike ul and ol, it's not meaningfully named at all. Honestly, I'm not a huge fan of recycling a deprecated element. If we need an element for side comments, we could introduce comment or c. If we need an element for document info, we could introduce info. That would make HTML elements more meaningfully named. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/15 Jukka K. Korpela jkorp...@cs.tut.fi 2012-07-14 18:51, Ian Yang wrote: If ol is no more and no less ordered than ul, what's the purpose of its introduction? The real purposes, in the dawn of HTML, were that ol and ul correspond to numbered and bulleted lists, respectively, reflecting two very common concepts in word processors. This is how they have been used, though some authors have started overusing ul for thinks like lists of links even when they specifically don't want them to appear as bulleted. Even W3C specifications, in their markup, switch to ul in the midst of hierarchy when they want bullets and not numbers. HTML5 tries to stick to the theoretical idea of ordered vs. unordered list, but it does not really change anything, and it is not supposed to change anything - any ul will still be rendered in the order written. More on this: http://www.cs.tut.fi/~**jkorpela/html/ul-ol.htmlhttp://www.cs.tut.fi/%7Ejkorpela/html/ul-ol.html Thanks. I'm not sure if I understand it correctly. I just couldn't find a robust information from the article to proof that ol is no more and no less ordered than ul. Throughout the article, I saw it mentioned bullets and numbers frequently. However, that's just browsers' default rendering of ul and ol. As a coder, personally I don't care how browsers render them by default. What I care is the meaning of the code I write. That is, when I want an unordered list, I write ul; when I want an ordered list, I write ol. ul means unordered list, and ol means ordered list. It's that simple. Although there may be some people misuse them (like the example mentioned in the article), that's not ul and ol's problem. If I missed anything, please let me know. Thanks again. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/16 Jukka K. Korpela jkorp...@cs.tut.fi 2012-07-15 17:40, Ian Yang wrote: Throughout the article, I saw it mentioned bullets and numbers frequently. However, that's just browsers' default rendering of ul and ol. It's the only real difference between the two. Sorry, I still don't get it. ul means unordered list; ol means ordered list. They are quite different, aren't they? As a coder, personally I don't care how browsers render them by default. You should. Check out the Usual CSS Caveats. Okay, actually I should say that browser's default rendering is not my *main concern*. I know browsers surely have their different default renderings of different list elements to help readers distinguishing them. But as a coder, my *main concern* is if the meaning of the code I write correspond the the content, not the their default renderings (because browsers will handle that). What I care is the meaning of the code I write. That is, when I want an unordered list, I write ul; when I want an ordered list, I write ol. ul means unordered list, and ol means ordered list. And what does that mean? Does it mean that browser may or will treat ul as unordered in the sense that it can render the items in any order? If not, what *is* the difference? Just some people's *calling* it unordered. Imo, ul means the order of the items is unimportant, not browsers can render the items in any order. If there were a browser which wants to render the items of ul in any order, okay, it may do that. Anyway, that's not my main concern. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/16 Leif H Silli xn--mlform-...@xn--mlform-iua.no Sat, 14 Jul 2012 23:53:32 +0800, from Ian Yang Okay, it seems that one of the ideas I mentioned in my original email needs to be revamped. I was saying that using general heading (H1) and paragraph (p) loses the meaning of definition term and definition description, but I didn't realize that using ol loses the meaning of definition list. That is, the following code is, in fact, improper: !-- The following code is improper as it loses the meaning of definition list. -- ol li dt/dt dd/dd /li li dt/dt dd/dd /li li dt/dt dd/dd /li /ol An XOXO list should solve this: http://microformats.org/wiki/**xoxo#Properties_of_Outline_**Itemshttp://microformats.org/wiki/xoxo#Properties_of_Outline_Items Or just add a dl wrapper around the dt/dd elements in your code above. Thanks for the useful information. I didn't know the XOXO thing before. However, after reading the examples they provided, I still couldn't understand its use. Could you please provide me with an example of the use of XOXO, using the life cycle of the butterfly I mentioned above? Thank you very much. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/14 Anne van Kesteren ann...@annevk.nl I would recommend not over-thinking the matter. Otherwise soon you will start wrapping your ps in ol/lis too to ensure they stay in the correct order. That wouldn't be the problem. General ps of an article never are list contents, so we surely won't wrap them in ol/lis. Using dl for ordered groups is perfectly fine. (The specification points this out as well: The order of the list of groups, and of the names and values within each group, may be significant.) Thanks for the info about the spec saying in dl the order of the list of groups *may* be significant. However, what it says means a dl itself is unable to tell whether its contents are unordered or ordered, and we have to judge that by ourselves. Comparing to ul and ol which themselves are able to tell whether their contents are unordered and ordered, the dl itself being unable to do that is, imho, disappointing. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
2012/7/14 Jukka K. Korpela jkorp...@cs.tut.fi Indeed. The ol element is no more and no less ordered than ul or any other element. Many HTML tag names are misleading. That's interesting. If ol is no more and no less ordered than ul, what's the purpose of its introduction? Could you provide detailed explanations or examples? Thanks. Sincerely, Ian Yang
Re: [whatwg] Suggest making dt and dd valid in ol
Okay, it seems that one of the ideas I mentioned in my original email needs to be revamped. I was saying that using general heading (H1) and paragraph (p) loses the meaning of definition term and definition description, but I didn't realize that using ol loses the meaning of definition list. That is, the following code is, in fact, improper: !-- The following code is improper as it loses the meaning of definition list. -- ol li dt/dt dd/dd /li li dt/dt dd/dd /li li dt/dt dd/dd /li /ol 2012/7/14 Anne van Kesteren ann...@annevk.nl I believe it was added to the specification for the kind of question that came up here. The why do we have ul and ol but not dl and odl? question. That's a good idea. Thank you :) So based on the ul and the ol, we could have unordered definition list ( udl) and ordered definition list (odl). When contents of a definition list are unordered, we could use: udl li dt/dt dd/dd /li li dt/dt dd/dd /li li dt/dt dd/dd /li /udl And when contents of a definition list are ordered, we could use: odl li dt/dt dd/dd /li li dt/dt dd/dd /li li dt/dt dd/dd /li /odl Sincerely, Ian Yang
[whatwg] content element, which we need in our documents
Hi editors in chief and everyone else, How have you been recently? As many of you may have been aware that there is an important sectioning element we have been short of for a long time: the content element. Remember how we sectioned our documents in those old days? It's the meaningless divs. We used them and added id=header, id=content, id=sidebar, and id=footer to them. After HTML5 came out, we started to have new and semantic elements like header, aside, and footer to improve our documents. However, today, we are still using the meaningless div for our content. The main content forms an important region. And we often wrap it with an element. By doing so, we distinguish the region from the header and the footer, and also prevent all of its child elements (block level or inline level) being incorrectly at the same level as the header and the footer. In the first example of the intro section of the nav element in HTML5 Spec ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the page takes a while to be fully loaded), the bottom note states: Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer. This example mentioned above is a typical situation that we need an element for the main content. So instead of keep wrapping our contents with the meaningless div, why not let the content element join HTML5? Sincerely, Ian Yang Meaningful and semantic HTML lover | Front-end developer
Re: [whatwg] content element, which we need in our documents
Please note that the example of the nav in HTML5 spec uses div to wrap all the contents of the page other than the header and footer. And developers always wrap contents with div id=content/div or div class=content/div. Your website does that, too. If everything is content, then we would have never seen codes mentioned above. Regards, Ian Yang 2012/6/29 Ashley Sheridan a...@ashleysheridan.co.uk Ian Yang ian.h...@gmail.com wrote: Hi editors in chief and everyone else, How have you been recently? As many of you may have been aware that there is an important sectioning element we have been short of for a long time: the content element. Remember how we sectioned our documents in those old days? It's the meaningless divs. We used them and added id=header, id=content, id=sidebar, and id=footer to them. After HTML5 came out, we started to have new and semantic elements like header, aside, and footer to improve our documents. However, today, we are still using the meaningless div for our content. The main content forms an important region. And we often wrap it with an element. By doing so, we distinguish the region from the header and the footer, and also prevent all of its child elements (block level or inline level) being incorrectly at the same level as the header and the footer. In the first example of the intro section of the nav element in HTML5 Spec ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the page takes a while to be fully loaded), the bottom note states: Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer. This example mentioned above is a typical situation that we need an element for the main content. So instead of keep wrapping our contents with the meaningless div, why not let the content element join HTML5? Sincerely, Ian Yang Meaningful and semantic HTML lover | Front-end developer I am pretty sure this was discussed a few months back and the answer was that everything is content, so no need for a content element. The header and footer just mark up areas of that content with special meaning, but its still all the main content. Thanks, Ash http://ashleysheridan.co.uk
Re: [whatwg] content element, which we need in our documents
As described in whatwg specs, a section, in this context, is a thematic grouping of content, typically with a heading. As for a article, which usually contains its own header and footer, is used to form an independent content like blog entry, comment, or application. Both section and article elements are not the candidate for containing a website or a blog entry's main content. That obviously is the reason that the example of the nav in HTML5 spec doesn't use them. Regards, Ian Yang 2012/6/29 Cameron Jones cmhjo...@gmail.com If the content is a special section within the document you should use the section element which has semantic meaning over div. Alternatively you could use article if it's distinct and self-contained. These two elements serve to disambiguate the abstract idea of content into something with semantic meaning which can be instrumented by document consumers. cam On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Ian Yang ian.h...@gmail.com wrote: Hi editors in chief and everyone else, How have you been recently? As many of you may have been aware that there is an important sectioning element we have been short of for a long time: the content element. Remember how we sectioned our documents in those old days? It's the meaningless divs. We used them and added id=header, id=content, id=sidebar, and id=footer to them. After HTML5 came out, we started to have new and semantic elements like header, aside, and footer to improve our documents. However, today, we are still using the meaningless div for our content. The main content forms an important region. And we often wrap it with an element. By doing so, we distinguish the region from the header and the footer, and also prevent all of its child elements (block level or inline level) being incorrectly at the same level as the header and the footer. In the first example of the intro section of the nav element in HTML5 Spec ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the page takes a while to be fully loaded), the bottom note states: Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer. This example mentioned above is a typical situation that we need an element for the main content. So instead of keep wrapping our contents with the meaningless div, why not let the content element join HTML5? Sincerely, Ian Yang Meaningful and semantic HTML lover | Front-end developer I am pretty sure this was discussed a few months back and the answer was that everything is content, so no need for a content element. The header and footer just mark up areas of that content with special meaning, but its still all the main content. Thanks, Ash http://ashleysheridan.co.uk
Re: [whatwg] content element, which we need in our documents
By analyzing the example in HTML5 spec, wrapping all content elements can make the structure of the document become more organized. After all, content elements all being at the same level of header and footer is unreasonable, and sometimes looks messy, especially when there are many different kinds of content elements (p, figure, pre, a, table, .. etc). 2012/6/29 Aurelio De Rosa aurelioder...@gmail.com I agree with Ian about the use of article and section, the specifications are really clear on those elements. The are used to wrap an entire entry, not the content (in the meaning Ian stated). The read question for me is: What is the problem of having the content at the same level of header and footer (for example inside an article)? Can't we treat everything inside an article which is not in header or footer is the real content? Best regards On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang ian.h...@gmail.com wrote: As described in whatwg specs, a section, in this context, is a thematic grouping of content, typically with a heading. As for a article, which usually contains its own header and footer, is used to form an independent content like blog entry, comment, or application. Both section and article elements are not the candidate for containing a website or a blog entry's main content. That obviously is the reason that the example of the nav in HTML5 spec doesn't use them. Regards, Ian Yang 2012/6/29 Cameron Jones cmhjo...@gmail.com If the content is a special section within the document you should use the section element which has semantic meaning over div. Alternatively you could use article if it's distinct and self-contained. These two elements serve to disambiguate the abstract idea of content into something with semantic meaning which can be instrumented by document consumers. cam On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Ian Yang ian.h...@gmail.com wrote: Hi editors in chief and everyone else, How have you been recently? As many of you may have been aware that there is an important sectioning element we have been short of for a long time: the content element. Remember how we sectioned our documents in those old days? It's the meaningless divs. We used them and added id=header, id=content, id=sidebar, and id=footer to them. After HTML5 came out, we started to have new and semantic elements like header, aside, and footer to improve our documents. However, today, we are still using the meaningless div for our content. The main content forms an important region. And we often wrap it with an element. By doing so, we distinguish the region from the header and the footer, and also prevent all of its child elements (block level or inline level) being incorrectly at the same level as the header and the footer. In the first example of the intro section of the nav element in HTML5 Spec ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the page takes a while to be fully loaded), the bottom note states: Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer. This example mentioned above is a typical situation that we need an element for the main content. So instead of keep wrapping our contents with the meaningless div, why not let the content element join HTML5? Sincerely, Ian Yang Meaningful and semantic HTML lover | Front-end developer I am pretty sure this was discussed a few months back and the answer was that everything is content, so no need for a content element. The header and footer just mark up areas of that content with special meaning, but its still all the main content. Thanks, Ash http://ashleysheridan.co.uk -- Aurelio De Rosa email: aurelioder...@gmail.com email: a.der...@audero.it website: www.audero.it user group: ug.audero.it
Re: [whatwg] content element, which we need in our documents
Hi Steve, Thank you. I understand. Regards, Ian 2012/6/29 Steve Faulkner faulkner.st...@gmail.com Hi Ian, ARIA fills the gap in HTML with role=main http://www.w3.org/TR/wai-aria/roles#main I agree that an explicit element would be nice, but the powers that be have rejected the idea. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
