Re: [whatwg] several messages about figure and related subjects
Le 2008-02-25 à 17:42, Ian Hickson a écrit : On Mon, 16 Jul 2007, Michel Fortin wrote: Since I'm not convinced that the current content model for figure is adequate [1], I decided to dig more examples where figures in HTML pages would be hard to fit with the current model. Here are the results. Thank you hugely for this research! This is very useful. I have updated the spec to handle these cases, and given examples of some of the key ones. Let me know if you think anything else deserves an example. I'm glad it was helpful. I quite like the new definition for figure and I think it covers the vast majority of illustration use cases I could come with. I don't think it needs more examples either. I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Note that there was a couple of such markup rendering examples like these at the end of the email you're referring to. Now, perhaps that case isn't important or frequent enough to justify adding it to the spec -- I won't be the juge of that -- but I have myself such a page on my website for which I'd like to use better markup than div class=html at each example (page included in the list in the old email) and I still don't see what I should use (was hoping for figure). It could also be useful to allow labeling of subfigures, perhaps like this: figure figurelegend(a)/legend img .../figure figurelegend(b)/legend img .../figure legendMy house seen (a) from the front; (b) from the back/ legend /figure This is allowed, but I haven't included an example. I don't think it's necessary. Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] several messages about section, p, hr, and related subjects
Le 2008-02-27 à 2:17, Ian Hickson a écrit : On Thu, 6 Apr 2006, Michel Fortin wrote: Le 6 avr. 2006 à 6:44, Alexey Feldgendler a écrit : This heading shouldn't be within the document's main tree of headings. It should be completely taken out, that's what aside means. But it can't be done in a backwards compatible way. Hum, that's true; it seems to be a general issue with asides, not limited to figures. Using aside to indicate a sidebar on a page shouldn't be much of a problem because the sidebar is usually outside of the main content and can have the same heading level as the main content. But aside content inserted in the middle of the text is already problematic from the semantic standpoint in HTML 4, and become a problem to any outliner if it contains headers. Maybe there could be a h element. This way you can use h1, h2, etc. for the main content and h for any content outside the main outline of the document, like asides. Its use wouldn't be mandatory, just like you don't have to use the right heading number anymore, but recommended for aside backward compatibility with outliners. It could also be used in the main content for the 7th heading level and beyond. I don't understand the problem being described here. The idea was to add h for use inside aside so you can remove the header from the main flow for old outliners not supporting the HTML5 outline algorithm. I don't think it has a very strong use-case; I was simply pointing it as a solution to the backward compatibility problem Alexey mentioned. Michel Fortin [EMAIL PROTECTED] http://michelf.com/
Re: [whatwg] Proposal for a link attribute to replace a href
Shannon schrieb: With the capabilities of modern browsers it seems to me that a specific tag for hyperlinks is no longer required or useful and could be depreciated with a more versatile global link attribute. I believe that hyperlinks now have more in common with attributes such as ONCLICK than they do with tags since in web applications links often define actions rather than simply being a part of the document structure. The A tag would continue its role as an anchor but the HREF attribute would be phased out making A a more consistent element (since links and anchors are really quite separate concepts). Below is an example of the proposed link attribute in action: lia href=foo.htmlFoo/a/li could be written as: li link=foo.htmlFoo/li No useful semantic information is lost however the markup is cleaner and the DOM drops an unnecessary node (which could speed up certain applications). I like this idea - this could significantly reduce the amount of scripting in web pages and applications, and thus increase the accessibility of hyperlinks. Anyway, why do you suggest a new attribute rather than making the existing href attribute global? li href=foo.htmlFoo/li That makes your idea backwards compatible - provided UAs interpret attributes of unknown tags, they will even be capable to correctly handle occurrences of a href when the A element will be totally removed from their code. -- Markus Ernst
Re: [whatwg] Proposal for a link attribute to replace a href
[... global attribute for links ...] We have a FAQ entry on this -- quite common -- request: http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F Hope that helps! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] several messages about figure and related subjects
On Wed, 27 Feb 2008, Michel Fortin wrote: I'm wondering however about the definition leaving something out. It says: The figure element represents some prose content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. Using figure here doesn't help. What you are illustrating in this case isn't what a header looks like, it's a section that happens to have a header. In fact the only difference between this case and the first example above is that the first example above breaks the outline, but you could work around that by doing this: pA header looks like this in your browser:/p sectionh1Some text!/h1/section ...and it would have roughly the same meaning as in the figure case. The problem is that there's no way to mark up content as being metacontent, that is, there's no way to mark up an element as having no semantics but its default presentation. This is a rare edge case which basically only affects tutorials and test cases. We could come up with a feature to annotate markup as being literal or meta rather than working as defined, but I don't see the point. Test cases aren't going to use it because they are trying to fake out the browser into thinking that some particular convoluted case is occuring, and frankly tutorials are better off not using it because otherwise people would copy and paste that without realising it is specific to tutorials. I recommend simply not worrying about it. In cases where you're self-referrentially discussing markup, the document's semantics don't really make sense. But that's ok, I don't think anyone but semantic nerds like us are going to really notice or care. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] The div element
Why does the HTML5 spec say The div element represents nothing at all ? [http://www.whatwg.org/specs/web-apps/current-work/#the-div] Div clearly stands for 'division', as was specified in the HTML 3.2 spec: DIV elements can be used to structure HTML documents as a hierarchy of divisions. [http://www.w3.org/TR/REC-html32#div] So what gives - why is everyone so keen to claim that 'div' is meaningless? And why so keen on 'section', which is pretty much synonymous in this context. Cheers, Please consider the environment before printing this e-mail. The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments.
Re: [whatwg] The div element
On Wed, Feb 27, 2008 at 7:38 PM, Geoff Pack [EMAIL PROTECTED] 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] Div clearly stands for 'division', as was specified in the HTML 3.2 spec: DIV elements can be used to structure HTML documents as a hierarchy of divisions. [http://www.w3.org/TR/REC-html32#div] So what gives - why is everyone so keen to claim that 'div' is meaningless? And why so keen on 'section', which is pretty much synonymous in this context. Cheers, That definition you quote gives the answer. ^_^ A division doesn't tell you *anything* about what the content of the div means, or what place it holds within the greater structure of the document. It's merely a 'division'. The lack of any further definition has led to its use for *anything* that needs grouping, leading to the term div-mania. I used divs all over the place when I first started coding, before I learned proper practices (luckily, the only applications were internal and aren't used anymore, so I didn't contribute to the poor state of the web ^_^). Even if you can divine some actual semantics out of the 3.2 definition, div has clearly lost all semantics in practice, which is what matters. section doesn't have quite that problem. It's a generic grouping element, true, but it is so in the same way that p is. It's designed to wrap *content* that's thematically related, and the examples give relatively clear usage guidelines. It may lose its semantics in practice, but we'll have to wait to see that. I'm hopeful, for several reasons. One, div already exists, and has spread to fill all niches naturally, leaving section little incentive to spread similarly. ^_^ As well, section's name is more specific and gives its semantics more clearly. Finally, a lot of the common places where div is currently used (and section could be applied) are instead filled with new elements, restricting section's ability to get a foothold in generic-ness. Anyway, we need a meaningless block-level element, the same as we need span for in-line content. It lets us fill in the holes that the spec fails to or refuses to cover, without muddying up the document's semantics. ~TJ Atkins
