Re: [WSG] semantics : was-[HR tag and Semantics]
On 07/02/07, Designer [EMAIL PROTECTED] wrote: I feel very restricted by the use of div (even with a descriptive identifier or class) because div means very little. I'm glad we have such things as p (and the rest!) because they make code easier to read. Well, the thing with a separator is, it doesn't in itself specify anything else than that the content on one side belongs does not belong to the same grouping as the content on the other side. But if you instead mark up each grouping with the appropriate semantical element, then you get the separation with the boundary. And while a separator element doesn't tell you at which semantic level the separation is, wrapping semantical elements for the content before and after the separation clearly specify this. The separator element signifies LESS than div element boundaries do, because the divs at least tell you at which level the separation takes place. However, a separator element can be used to strengthen the semantic importance of that boundary if placed between the wrapping elements. However, consider a node tree like this: h1 p h2 p h3 p hr p hr p.copyright Okay, we can assume the copyright paragraph is conceptually at top level, since it's likely a footer. Could a machine tell? No, because the hr doesn't give any information more than it being a separator, not at what level the separation takes place. It's our knowledge of language that tells us it probably doesn't belong to the content sections of the h1, the h2 or the h3 however. But tell me, the paragraph before that hr, does that paragraph belong conceptually at the top level, at the h1, the h2 or the h3 level? Compare to this: section h p section h p section h p separator (redundant) p separator (redundant) p.copyright Suddenly, the separation by wrapper boundaries makes it very clear at which level the separation takes place. The separator elements are redundant, but can be used to emphasise the conceptual separation. And if you want an emphasis on the separation level, a better choice would be to wrap the paragraphs in question by a headless section element instead of preceding them with a separator element. Roll on xhtml 5! However I suspect this is way way down the line and everything will have changed anyway. Well, if by XHTML 5 you mean WA1.0, then it'll probably be a standard years before you can find two implementations, not to speak of interoperable implementations, of XHTML 2. In the meantime, the less divs I can use, the better . . . As long as there's something that semantically fits better than this content is conceptually closer grouped than the surrounding content, go ahead. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantics : was-[HR tag and Semantics]
On 07/02/07, Jens Brueckmann [EMAIL PROTECTED] wrote: On 07/02/07, liorean [EMAIL PROTECTED] wrote: But if you instead mark up each grouping with the appropriate semantical element, then you get the separation with the boundary. I do question this. The boundary is void, nothing, whereas a specific element denoting a separation of two different sections is itsself part of the overall content. Well, it could be a conclusion, and ending. Or for that matter a beginning, a clean break. Or the transition, if the boundary is fuzzy. If either of the first two, it should probably be part of the grouping it concludes or begins. If the third, I'm not sure there's any semantically fitting element. Maybe the transition itself should be a separate, short, grouping of it's own. In this case, the separator element is possibly even the best solution. Monty Python's Flying Circus would certainly miss something if the words And Now For Something Completely Different did not exist. This phrase is actually a separator, it has meaning. I think the same applies to separators in markup. Well, that is what I would call a transition. And you're right, it's a separator. But it's also content. It's definitely say it's not equivalent to an hr; the hr may be a separation semantically, but it isn't content. The problem of trying to fit a greyscale world - or maybe even hsla colour with gamma correction - into black and white. Markup always has the problem of trying to put semantics to well defined areas, excluding it outside those areas. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Usability Questions for Quicktime
On 06/02/07, Christian Montoya [EMAIL PROTECTED] wrote: Quicktime works well with IE browsers, but with other browsers it's hit and miss. All too often I have seen my browser (FF 2.0) crash as a result of a Quicktime movie. Flash never crashes. Regardless of which consumes more resources (and if Flash is slow you are doing it wrong), Flash is much more dependable. I find all my Quicktime plugin problems are not Apple's fault, but third party. Namely, VLC tries to steal Quicktime (and Windows Media) types of files, and the VLC plugin is not at all as stable as Quicktime. But that's just my system. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HR tag and Semantics
On 06/02/07, Kat [EMAIL PROTECTED] wrote: What is the difference between the new section and a div ? Sections are typographical sections, divs are for adding extra structure. You can see divs as fuzzy semantically distinct content areas and sections as a textual semantical grouping. uri:http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.8. uri:http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.4. Also IIRC the hr is just renamed to separator in XHTML2, it doesn't go away entirely. uri:http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.9. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Smallest valid html document (was validator.w3.org broken?)
Shortest DTD-valid HTML 4.01 Strict document, with the root element being HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//ENTITLE//P However, you don't need to choose HTML as your root element. This document is DTD-valid HTML4.01 Strict. !DOCTYPE P PUBLIC -//W3C//DTD HTML 4.01//EN -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Standards War - HTML 5 vs XHTML 2.0
On 1/27/07, Paul Ross [EMAIL PROTECTED] wrote: Is this a fork in the specs road or a standards war in the making? It would be great to bounce this off the WSG cogniscienti and help me (and maybe others?) get a grasp of what is going on here. W3C went too far in their ambitions with XHTML2. They decided to throw away the good with the bad and make a single, huge change to HTML (including a full replacement of the SGML/Tagsoup foundation by XML with draconian error handling) that is in many ways incompatible with current HTML. The result is a too time consuming process to produce a specification of a language that is so different that none of the current user agents for HTML, whether browsers, editors, spiders etc. can add it's features without major changes. XHTML2 if it were to get finished today it would be DOA as there's not a single browser and to my knowledge no editing tools that even considers supporting it at the moment. The fact that it's still a WD and nowhere near becoming a standard right now indeed makes it a bad idea for implementors currently. But in a future with browser and editor support for generic XML and custom XML applications that is much stronger than the current situation, XHTML2 might eventually displace HTML. You must understand, XHTML2 is a different language than HTML, it will compete with HTML - not a specific version of HTML such as HTML5 or HTML4.01, but HTML as a sloppy error recovered document language in general - as well as with XHTML for filling the same role, with the forced draconian error handling of XML and with different semantics from HTML/XHTML. HTML5 on the other hand is developed in an open process supported by the browser makers themselves (except Microsoft) and is meant to be an evolution of HTML rather than a replacement. It doesn't require major changes, it only adds on top of the current HTML standard. It tries to standardise things that were never standardised before such as parser error recovery. Parts of it are already implemented in several browsers. XHTML2 and HTML5 are not at the moment competitors. XHTML2 isn't on the horizon yet, but HTML5 is in sight. If anything, what's happening is that HTML5 will succeed HTML4.01 as the current HTML standard in a few years. When mature enough, XHTML2 may become an alternative to the then current HTML, whichever version that is. But XHTML2 has always been a whole new technology trying to replace HTML. HTML5 is instead an evolution, an upgrade, of an aging HTML specification. Oh, and HTML5 will probably become a W3C specification, if HTML WG and WhatWG cooperation works out: uri:http://www.w3.org/2006/11/HTML-WG-charter.html -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] The Name Attribute??
On 15/05/06, Debbie T [EMAIL PROTECTED] wrote: I think it threw me a little when I tested a strict xhtml document with an internal anchor using name and the validator passed it. The xhtml validator is usually pretty good with picking out deprecated elements. Perhaps because, as you said, it is not deprecated in every element, so it is difficult for the validator to decifer how it was being used. Actually, deprecation does not mean invalidation. Some of the elements in which the name attributes were deprecated in XHTML had their name attributes removed from the XHTML1.0 Strict DTD. However, the a element is one of those elements that didn't have it removed. That doesn't mean it hasn't mean deprecated, though, it just means it will be removed in a future version instead. If I were to give a guess as to the reason for it being kept on a elements, that reason would be that the user agents present at standardisation time did not prove to give sufficient support to using the id attribute in the same function as the name attribute on a elements - namely, as fragment identifiers. -- David liorean Andersson uri:http://liorean.web-graphics.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
