Search the Community

Hello, I’m restructuring the html code of my site to have the best semantic markup as possible but I struggle with the <article> and <section> tags. I know there are lots of documentations on the internet on how to use these tags. I’ve read many of them but the more I read about <article> and <section>, the more I get confused on how to use them properly, mainly because I’ve seen a lot of contradictory examples from a site to another. I understand that a <section> is used to regroup elements sharing information on a similar thematic whereas an <article> refers to an independent content that is reusable outside the document. It sounds simple in theory but in practice, it's very tricky, at least for me. I’ve made different templates of my "about" page which is he most complex page I have (in regard to semantic), and I would appreciate if you could tell me which of the following images is the most semantically correct or if you have other suggestions I could take into consideration. Beside the <section>/<article> thing, I also question myself on the need of using a single <section> in the <main> container… Do I need to regroup all my "about" elements inside a <section> tag if there is no other <section> in the document? Fig. a Fig. b and 4b -> just like 3b with the blue containers being different <section> instead of being different <article>. 4b is how my page is currently structured. Any help would be appreciated. Thanks!

Hi guys! I just went through difficult maintenance for a website project involving iframes with the necessity of short, not embedded initial content. I was using @srcdoc and it already was difficult enough as syntax rules. Then I changed mime type for the pages, converting them into proper XHTML, and the result was confusing and terrible: Syntax adjustments for the "markup model" inside the attribute's value made me double the length of the value. It is not checked by validator, so predicting errors is difficult. It relies on the support of @seamless in order to match the design of the page, or otherwise it needs style declaration/stylesheet embedding which make it longer and impact on page loading while using several iframes in the page. Anyway using both could lead to conflicts during the (future, eventual) transition phase when @seamless is implemented on some UAs but not all and/or we'll have to face both support and backward compatibility. inserting semantic markup is too long because it ends up being treated as external document, so there must me a link reference to the main argument which is pointless (IMO), as the content is actually part of the page containing the main argument itself. XML serialization is wrong also in those browsers which currently support @srcdoc: Firefox always parses it as HTML, while the other ones complete the srcdoc document with tags missing (following the spec rules about tag omission in text/html) also where this is not requested. @srcdoc syntax is difficult to find, read, parse and serialize for any client different from browsers, i.e. search engines, data mining tools, scripts which fetch documents, and even for the authors themselves which have to write proper scripts for retrieving data (perhaps from databases) and insert them in a so particular position (with a special syntax inside an attribute) it is theoretically confusing because it mixes elements and attributes. It forces authors to write unmaintainable document fragments, also denying them the use of common editing aids like indentation and markup highlighting. These reasons and many more make iframe@srcdoc practically unusable now and in the near future. It is not a case that in webpages fetched by webdevdata as of october 2013 no use of @srcdoc has ever been made. And I suppose neither is a case that iframe@srcdoc is the very only feature making use of a "markup model" inside an attribute value. Now, iframe is not a void element: the restrictions on content, different between HTML (content model: text) and XHTML (content model: empty) documents, have been introduced with HTML5. Has anyone ever thought that the very same results of @srcdoc, with better, richer and more practical result using the native <iframe>'s content?