Re: [whatwg] Proposal for a link attribute to replace a href
Paweł Stradomski wrote: W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). Sorry, I should have explained that better (always in a rush to get my thoughts down), it was just a snippet that is actually inside a form. But you're right of course. Within a form wouldn't inputs with a type=button be appropriate? Why do we have type=button if it's completely useless without scripting? I view a checkout process as a multi-page form so my thinking was that from a user-perspective clicking buttons makes something happen in the scope of the form and does not 'take you elsewhere' as such regardless of what really goes on. It could get confusing but I'd definitely find it useful to apply to div elements and list items. Thanks for pointing that out, Robert
Re: [whatwg] Proposal for a link attribute to replace a href
Philip Taylor wrote: On 28/02/2008, Shannon [EMAIL PROTECTED] wrote: A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. Are there cases where div ...a href=... style=display:block; width:100%; height:100% ... /a/div is not adequate for making block links? If you could nest block elements inside a and have it validate then no. Would this be a possibility? Seems like it wouldn't be too difficult to implement if it's just a question of what validates and what doesn't. I guess a global attribute isn't the right thing.
Re: [whatwg] ARIA
Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. -- Mixed up signals Bullet train People snuffed out in the brutal rain --Conner Oberst
[whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
[EMAIL PROTECTED] wrote: I would like something to indicate that text should not be rendered by the UA but still remain accessible. Content that should be available to screen readers but not have a visual representation is, in fact, relevant. Indeed, which is why such content would not have @irrelevant set. It is content that should be ignored in all UAs would have @irrelevant set. At the moment AT generally tries to infer semantics from the presentation layer (this is display:none so it must be irrelevant), which is why hacks like the one you describe are needed. The irrelevant attribute allows these semantics to be encoded at the markup layer. The biggest problem I can see with this argument for @irrelevant is that it's not quite clear to how to get from where we are today (AT takes account of CSS CSS display properties rather than markup) to the behavior described above. If rendering display:none content that doesn't have the irrelevant attribute set results in a significantly worse web experience than not doing so then AT vendors will presumably be reluctant change behavior. We probably need some investigation into the effect that this change would have on the user experience for AT users. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] several messages about handling encodings in HTML
Dnia 29-02-2008, Pt o godzinie 01:21 +, Ian Hickson pisze: In 8.2.2.4, I have no idea what's the reason or purpose of point 1, which reads If the new encoding is UTF-16, change it to UTF-8.. I suspect some misunderstanding. This is required because many pages are labelled as UTF-16 but actually use UTF-8. For example: http://www.zingermans.com UTF‒16 cannot be transmitted over Internet anyway so it must be changed to something because what comes in is certainly not UTF‒16-encoded. This declaration is in error; one of the possible universal encodings UTF‒8, UTF‒16LE and UTF‒16BE should be chosen that produces valid markup for the decoded document. Chris
Re: [whatwg] several messages about content sniffing in HTML
On 29 Feb 2008, at 16:33, Julian Reschke wrote: Geoffrey Sneddon wrote: It seems like the HTTP spec should define how to handle that, but the HTTP working group has indicated a desire to not specify error handling behaviour, so I guess it's up to us. IE and Safari use the first one, Firefox and Opera use the last one. I guess we'll use the first one. Isn't the fact that FF and IE disagree here an indication that this doesn't need to be specified? Things aren't specified well enough until I can write an HTTP UA that can work in the real world (which, as someone dealing with feeds, I can tell you need without question support for content- type sniffing) from reading specifications without having to reverse-engineer anything. ... Doesn't seem to apply to this case. A duplicate Content-Type header response indicates that the response is invalid. And guess what? Users don't like error messages. I want to know how to deal with it without having to look elsewhere (from the spec). Apparently, most browsers accept the response anyway, some of which picking the first value, others the second. Both behaviors seem to be acceptable to users. So there's nothing you *need* to reverse engineer in this case. A page (http://www.toledoblade.com/apps/pbcs.dll/section?Category=RSS01mime=XML ) that I came across recently had: Content-Type: XML Content-Type: text/XML Using the first would break badly. I guess it seems to work because of content-type sniffing on an unknown (and invalid) header (or, as many feed readers do, totally ignoring it, with the exception of any charset parameter). Without content-type sniffing, that HTML 5 now allows, you need the last. But as James says: how do I know that which behaviour I choose doesn't matter until I reverse engineer browsers to discover that? -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] Proposal for a link attribute to replace a href
On 29 Feb 2008, at 01:29, Shannon wrote: Geoffrey Sneddon wrote: While yes, you could rely on something like that, it totally breaks in any user agent without scripting support. Nothing else, to my knowledge, in HTML 5 leads to total loss of functionality without JavaScript whatsoever. By total loss of functionality I meant something that is functionality provided by HTML itself (and not through CSS or some DOM API) which leads to the page being totally unusable. Well nothing except global/session/database storage, You already have the fallback for people without ECMAScript, so that works fine. the irrelevant attribute, So you can edit something which you otherwise couldn't. Oh well. Nothing breaks. contenteditable, Oh come on. Even IE supports this. This most certainly is backwards compatible. contextmenu, Again, this is a DOM API and can be recreated in ECMAScript (which, if you're try to use it at all, you know is enabled). draggable, Both IE and Safari have partial support for this already. the video and audio elements, canvas All three of these have fallback content, which is needed sometimes when a browser does support HTML 5 anyway. and the connection interface. Again, you know you have ECMAScript enabled already to be able to use this at all. Something similar could be done using XMLHttpRequest, if I am not mistaken. -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] The div element
On Fri, Feb 29, 2008 at 11:39 AM, Nicholas Zakas [EMAIL PROTECTED] wrote: I don't think it's as clear as you make it out to be. A section and a division. I hate to consult a dictionary on this, but one definition for section is subdivision. The naming alone does not make it clear what the difference is. The nav/, header/, and footer/ elements are pretty clear as to their usage. Some additional language might be good for clarifying. Optionally, got any better suggestions for the element's name? Anne mentioned that section/ interacts with h1/-h6/...how so? In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. If section/ is something people believe in, then there really has to be more definition around it and its difference with div/. I know part of HTML 5 is to mitigate the div-itis problem, but without clearer distinctions you'll just end up with a mishmash of section/ and div/ being used interchangeably. Okay, let's make sure it's clear. section has a pretty anemic description in the spec currently. To the best of my knowledge, the basic use case of section is dividing up related content within an article. This is pretty easy to use correctly. Question to others: I think it is somewhat unclear what exactly the correct semantics are for section when it is encountered outside of an article. Since section is the most generic of the sectioning tags, there is a definite risk of it falling into the same hole that div is in. Where exactly should section be used when outside of an article, and when should we just default to the div? ~TJ
Re: [whatwg] several messages about content sniffing in HTML
Geoffrey Sneddon wrote: Content-Type: XML Content-Type: text/XML Using the first would break badly. I guess it seems to work because of content-type sniffing on an unknown (and invalid) header Or because the header parser uses the first header that actually looks like a valid content-type (e.g. contains a '/'). Specifying this _is_ needed. -Boris
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? -Nicholas - Original Message From: James Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Friday, February 29, 2008 3:58:25 AM Subject: @Irrelevant [was: Re: [whatwg] Thoughts on HTML 5] [EMAIL PROTECTED] wrote: I would like something to indicate that text should not be rendered by the UA but still remain accessible. Content that should be available to screen readers but not have a visual representation is, in fact, relevant. Indeed, which is why such content would not have @irrelevant set. It is content that should be ignored in all UAs would have @irrelevant set. At the moment AT generally tries to infer semantics from the presentation layer (this is display:none so it must be irrelevant), which is why hacks like the one you describe are needed. The irrelevant attribute allows these semantics to be encoded at the markup layer. The biggest problem I can see with this argument for @irrelevant is that it's not quite clear to how to get from where we are today (AT takes account of CSS CSS display properties rather than markup) to the behavior described above. If rendering display:none content that doesn't have the irrelevant attribute set results in a significantly worse web experience than not doing so then AT vendors will presumably be reluctant change behavior. We probably need some investigation into the effect that this change would have on the user experience for AT users. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] Proposal for a link attribute to replace a href
On 28/02/2008, Robert O'Rourke [EMAIL PROTECTED] wrote: I don't understand why buttons should not be allowed an href, obviously when the button or input is to submit a form (ie. explicitly having type=submit as an attribute) it shouldn't be allowed but I'd find it useful where I've had to style a collection of links and inputs to be similar, for example the steps for a checkout process: One has to be careful here. You're absolutely right that form submission buttons need to be treated specially, as otherwise users' web accelerator software will start checking out their shopping carts, etc. I'm concerned that in all the exuberance to make more elements links, various basic problems like this might get overlooked. Sam
Re: [whatwg] several messages about handling encodings in HTML
On 29 Feb 2008, at 01:21, Ian Hickson wrote: - Again there, shouldn't we be given unicode codepoints for that (as it'll be a unicode string)? Not sure what you mean. This is just me being incredibly dumb. Ignore it. On Sat, 26 May 2007, Henri Sivonen wrote: The draft says: A leading U+FEFF BYTE ORDER MARK (BOM) must be dropped if present. That's reasonable for UTF-8 when the encoding has been established by other means. However, when the encoding is UTF-16LE or UTF-16BE (i.e. supposed to be signatureless), do we really want to drop the BOM silently? Shouldn't it count as a character that is in error? Do the UTF-16LE and UTF-16BE specs make a leading BOM an error? If yes, then we don't have to say anything, it's already an error. If not, what's the advantage of complaining about the BOM in this case? I don't see anything making a BOM illegal in UTF-16LE/UTF-16BE, in fact, the only mention I find of it with regards to either in Unicode 5.0 is In UTF-16(BE|LE), an initial byte sequence (FE FF|FF FE) is interpreted as U+FEFF zero width no-break space. I suppose the rational given for removing it is the section that follows D101 (e.g., When converting between different encoding schemes…UTF-8 byte sequences is not recommended by the Unicode Standard.). -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] The div element
Tab Atkins Jr. wrote (with snippage): In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. That doesn't sound correct to me. If they were all the same we could drop h1 to h6 and just use h. Section 3.8.6 states: These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank. Regards, Dave
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
On Fri, 29 Feb 2008 18:54:08 +0100, Nicholas C. Zakas [EMAIL PROTECTED] wrote: If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? The attribute, as explained in the specification (maybe it's not clear enough?) is intended for dynamic applications where you already have sections in the page for several steps, but only one of those sections is currently relevant. The rest is marked irrelevant until the user completes some action. This is a totally different case from the one you seem to be worried about. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] The div element
On Fri, Feb 29, 2008 at 1:04 PM, Dave Hodder [EMAIL PROTECTED] wrote: Tab Atkins Jr. wrote (with snippage): In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. That doesn't sound correct to me. If they were all the same we could drop h1 to h6 and just use h. Section 3.8.6 states: These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank. Regards, Dave Some clarification: The hn elements do still have a rank, and this is used when determining implicit sections. Frex, if I have a page consisting of an h1, some content, another h1, some content, an h2, and then some content, I end up with two implicit sections, with the second containing an implicit subsection. When doing explicit sectioning (that is, with the section element), the first heading element within a section(an hn or header tag) is taken as the heading for that section, regardless of the rank of headers used previously. That is, the n in hn is ignored in favor of the explicitly designated section. HTML5 didn't switch to simply using h (or heading or something like that) because that would prevent legacy user agents from doing their own implicit sectioning properly. Using pure h1 interferes with this somewhat as well, but it also greatly simplifies the use of headings, which was one of the reasons to create an explicit section element in the first place. This is over in the Headings Sectionshttp://www.w3.org/html/wg/html5/#headings0area. As well, I would swear that Ian said that bit about using pure h1s, but I can't find it at the moment. ~TJ
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
From this thread, it seems like the true purpose of irrelevant is to add to HTML the logical equivalent of display:none in CSS. If that is true, then I'd agree with Jeff that renaming the attribute ignore or omit is a good idea. Can anyone either confirm or deny the purpose of this attribute as the following description: This attribute is used to indicate part of a document whose content is not considered primary to the page. In visual UAs, elements with this attribute are not rendered; in non-visual UAs, elements with this attribute are not read as part of the normal content flow. Thoughts? -Nicholas - Original Message From: Jeff Walden [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: James Graham [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Friday, February 29, 2008 11:41:41 AM Subject: Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5] Nicholas C. Zakas wrote: If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? Unnecessarily suggests a particular medium of display; I suggest the shorter alternatives ignore(d) or omit(ted) if you really want the functionality. The biggest problem with the attribute is the spec doesn't sufficiently clearly describe the motivation for it; I suggest mentioning the preloading of iframes as such an example (they don't load/render if they're display:none, so it's either visibility:hidden (?) or launching the element into outer space offscreen with position/top/left), perhaps in an informative paragraph. Jeff Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[whatwg] Can dialog/ be renamed?
As discussed earlier this week, the dialog/ element is confusing in that the term dialog in software engineering typically means dialog window. I first thought the element was a way to indicate that a part of the page was used as a dialog rather than part of the normal content flow. I understand the need to disambiguate the use of the dl/ element, keeping it as a definition list, so how about cl/ for a conversation list? -Nicholas Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] The div element
From this description, it seems like the section/ element has little use. If you're talking about writing articles, most authors consider the start and end of sections as implicitly defined by headings. Making this explicit seems unnecessary so long as headings are still available and used. It's just extra syntax to represent something that is more easily represented without it. -Nicholas - Original Message From: Tab Atkins Jr. [EMAIL PROTECTED] To: whatwg List [EMAIL PROTECTED] Sent: Friday, February 29, 2008 10:24:49 AM Subject: Re: [whatwg] The div element On Fri, Feb 29, 2008 at 11:39 AM, Nicholas Zakas [EMAIL PROTECTED] wrote: I don't think it's as clear as you make it out to be. A section and a division. I hate to consult a dictionary on this, but one definition for section is subdivision. The naming alone does not make it clear what the difference is. The nav/, header/, and footer/ elements are pretty clear as to their usage. Some additional language might be good for clarifying. Optionally, got any better suggestions for the element's name? Anne mentioned that section/ interacts with h1/-h6/...how so? In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. If section/ is something people believe in, then there really has to be more definition around it and its difference with div/. I know part of HTML 5 is to mitigate the div-itis problem, but without clearer distinctions you'll just end up with a mishmash of section/ and div/ being used interchangeably. Okay, let's make sure it's clear. section has a pretty anemic description in the spec currently. To the best of my knowledge, the basic use case of section is dividing up related content within an article. This is pretty easy to use correctly. Question to others: I think it is somewhat unclear what exactly the correct semantics are for section when it is encountered outside of an article. Since section is the most generic of the sectioning tags, there is a definite risk of it falling into the same hole that div is in. Where exactly should section be used when outside of an article, and when should we just default to the div? ~TJ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] The div element
Sorry for the double for those of you on both lists. I sent a reply to the wrong mailing list again :( On 01/03/2008, Nicholas C. Zakas [EMAIL PROTECTED] wrote: From this description, it seems like the section/ element has little use. If you're talking about writing articles, most authors consider the start and end of sections as implicitly defined by headings. Making this explicit seems unnecessary so long as headings are still available and used. It's just extra syntax to represent something that is more easily represented without it. Sections allow some things that are impossible with the outline hierarchy of HTML4. In HTML4, once you had a header you needed a header of the same level or higher to make a paragraph not belong to that header. With sections you can make paragraphs belong to headers above the immediately preceeding one. You can have paragraphs that do not belong where they would in the HTML4 outline hierarchy. For example you can have a third level header as direct child of a first level header in the outline, even if there is a second level header before it. Sections allow stopping the association between a header and all that comes after it at some point. HTML4 outline hierarchy couldn't do this. Section is as I recall an idea imported from XHTML2. From what I understood, sections were originally meant to relate to sections of the information content as differentiated from divisions of the document structure. -- David liorean Andersson
