Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: The element grouplabel gives the label for the group. That's similar to the label group= idea I posted. True, but it eliminates the need for an |info| attribute on every element. Oops. Those info attributes were a copy and paste error. They should have been removed from #1 and #2, cause I wrote #3 first and copied that for the rest. The group attribute in my examples was referring to the name attribute, like the for attribute in yours. A better solution would be to use input group=, where the value of |group| is the value of the controls' |name| attributes and not the value of |info| attributes, thus eliminating the need for |info|. Assuming you meant label group=, that's exactly what I intended in my examples. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Lachlan Hunt wrote: Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html Joe Clark has responed. http://lachy.id.au/log/2006/10/fixing-html#comment-713 His comment is copied here for discussion. annotation: A lot of things are annotations in PDF, including comments. We could use annotation for suprasegmental features like very long tooltips with block-level content, whose appearance could be user-controlled (and accessible by screen readers and keyboard). We could also just call blog comments annotations. part, section and article (some in “HTML5”): A part can be a chapter (we could also just say “chapter”). Articles could be included in sections that are in turn included in parts and served as pages. caption generically applicable to tables and figures: We can call it legend if you’d like. bibliographies, tables of contents, and indices (some in “HTML5”): “For tables of contents, isn’t existing list markup good enough?” No, I’d prefer stronger associations between ToC and item than just a hyperlink. I would also like to be able to suppress display of ToC in some presentations. Of course I can do that with divs. nonstruct for generic groupings: We can use it to group noncontiguous elements, useful in e.g. error reports on submitted forms or Ajax applications. E.g., nonstruct group=”X”. Error reports are a good use case, but I'm not sure that nonstruct would be best for them. There are accessibility reasons for explicitly marking up error information, particularly for forms, and current accessible techniques include writing the error message within the label and/or fieldset's legend to force screen readers to read it out. Some markup for errors and a way to associate that error with a control might be useful. formula: “But doesn’t that fit into the category of science and mathematics that you had issues with earlier?” Yes, but this one we *need*. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Hi, From: Lachlan Hunt [EMAIL PROTECTED] I believe the issue is with the way screen readers handle existing forms. The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. pGender: label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /p In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out Male and Female, it won't read out Gender:. In this specific case, that's probably not a major issue because male and female are fairly self explanitory, but there are many cases where it's not. There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset I thought this was exactly what fieldset was designed to do. Group related form controls. Why do you consider it a workaround? Because of the way screen readers work, they now read out Gender: Male and Gender: Female as they tab to each control. This example demonstrates this technique. http://www.alistapart.com/d/prettyaccessibleforms/example_3/ The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. I'd propose fixing the styling issues instead of changing the markup. Alternatively screen readers could be made smarter, also without changing the markup. Consider: pGender: labelinput name=g value=m type=radio male/label labelinput name=g value=f type=radio female/label/p Now the screen reader finds a group of radio buttons not in a fieldset. Radio buttons almost always have a question assigned to them. So go up a level in the tree (to the P) and get its child text nodes or .textContent or something, and use that as the legend for the radio group. (I'm not saying this algorithm is fool-proof, just saying that we don't necessarily need to change the markup to solve this issue.) Regards, Simon Pieters _ Eragon på vita duken 15/12! http://www.msn.se/noje/eragon/
Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: Here's a thought: | p | grouplabel for=genderGender:/grouplabel |labelinput type=radio name=gender value=mMale/label |labelinput type=radio name=gender value=fFemale/label | /p The element grouplabel gives the label for the group. That's similar to the label group= idea I posted. The |for| attribute in this case takes a name rather than and ID, I think that could be somewhat confusing using the same attribute name for different, but somewhat related, features. That's why I like the group attribute, because then there's no chance for confusion about whether it takes a name or id in this context. Also, label already supported, so there's fewer backwards compatibility issues. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Hey Joe, Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ Note that in general I would encourage you to post your suggestions straight to the WHATWG list, as it is not guarenteed that I will always see your blog posts (though in this case, at least three separate systems and people alerted me to your post, so...). If you are under the impression that I am lending de facto support to WHAT WG, I'm not. Nor am I opposing WHAT WG. My concern is that WHAT WG is doing exactly what the W3C did. Due in no small part to WHAT WG's leadership by a strict standardista with an interest in video games, HTML5 replicates HTML's obsession with computer-science and math elements. * HTML has samp, var, and kbd. I use all of them and I am pretty much the only one who does. * HTML5 has meter (for measurements) and t for time notation. But, true to member biases, HTML5 bans the use of dl-dt/dd for dialogue, a usage permitted by the HTML spec and in wide use by intelligent developers like me who have to mark up documents unrelated to computer science. (They'd prefer you use a thicket of blockquotes and cites. And, presumably, nullify all the indention and italicization that browsers will do by default.) Dialogue is an open issue. What the spec says about the matter today is certainly not the end of the discussion. Indeed there was recently a thread (which I will be getting to when I next look at list elements) about this very issue. (I'm starting to think that we may need a separate set of elements... maybe dialog... with dt and dd -- dialog talker and dialog... discourse? I dunno, whatever -- but the point is it would be backwards compatible with legacy UAs.) This is a classic problem in HTML development: The people doing the work are geeks with computer-science interests who do not understand, for example, newspapers, or screenplays, or, really, print publishing in general. In some obscure way, they disdain print publishing, as the Web is not print. Indeed it isn't, but print has structures the Web doesn't, and it doesn't have them because people like these refuse to acknowledge they exist or simply refuse to consider them. Note that while it certainly is true that I'm a geek who doesn't understand many things outside my sphere of interests, it is _not_ true that such concerns are being intentionally ignored here. I encourge you and anyone else who has desires for what HTML should do to speak up. This attitude - still present in WHAT WG, though it is separate and was formed later - can be summed up as Until we decide you are using our computer-science tags adequately, we won't even consider the semantic needs of your documents. I find the attitude ill-educated and uncultured. It's Comic Book Guy deciding what will and won't be legal on your own Web page. Again, that certainly isn't the intent. Please be vocal in your suggestions for HTML5. They will be taken into account in due course. We have already added elements for time, headers, footers, sections, navigation, and so forth, based especially on quantified author needs (some of the results of the studies made for these purposes were published on the code.google.com site). We assuredly could use elements from tagged PDF like: [...] * annotation Could you elaborate on this? * note and reference for footnotes, endnotes, and sidenotes (not aside in HTML5) Could you elaborate on this? Does the title attribute cover this case? What do you need that isn't covered by title? * part, section and article (some in HTML5) Could you elaborate on what isn't included? * caption generically applicable to tables and figures This is something that will be considered (possibly relatively soon). * bibliographies, tables of contents, and indices (some in HTML5) Could you elaborate on what isn't covered here? * nonstruct for generic groupings Could you elaborate on what it is that div and span don't cover here? * formula Math in HTML5 is an area that is undergoing active research at the moment. Why not just borrow those? Why give us a way to mark up measurements but no way to mark up structural elements in layouts like footnotes and deks? Because the people asking for gauges were vocal and gave solid use cases, while the people asking for deks were not. I have no idea what a dek is. If you could elaborate on your use cases, give examples, show Web pages that are working around the absence of an element for the purpose, etc, then that would be a huge help. As you said, I'm a geek, and I don't know about things outside my realms of interest. WHATWG is completely open; your input and the input of everyone else is not only accepted, it's desired. Please help us, tell us what you want, why you want it, how you get around the lack of it today. (Note: meter is actually a gauge UI element, not a measurement element.)
Re: [whatwg] How not to fix HTML
On Mon, 30 Oct 2006, Joao Eiras wrote: Ian Hickson [EMAIL PROTECTED] escreveu: * Make embed legal. Give it up, people: object doesn't work and never will. HTML5 will make emded legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't. Why not? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How not to fix HTML
Na , Ian Hickson [EMAIL PROTECTED] escreveu: On Mon, 30 Oct 2006, Joao Eiras wrote: Ian Hickson [EMAIL PROTECTED] escreveu: * Make embed legal. Give it up, people: object doesn't work and never will. HTML5 will make emded legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't. Why not? Embed doesn't provide a fallback mechanism, and mixing parameters to the plugin, and attributes can be error prone, depending on the plugin, while object makes use of param.
Re: [whatwg] How not to fix HTML
On Mon, 30 Oct 2006, Joao Eiras wrote: Browsers will continue to suport embed, but the recomendations shouldn't. Why not? Embed doesn't provide a fallback mechanism, and mixing parameters to the plugin, and attributes can be error prone, depending on the plugin, while object makes use of param. Sure but, everyone uses embed, and object doesn't (in practice) work that well really. Also, object is overloaded to do things like IFrames, and images, and plugins... having embed just for plugins would make it like img and iframe, the simple object for plugins. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How not to fix HTML
Hello,On 10/30/06, Ian Hickson [EMAIL PROTECTED] wrote: Hey Joe,Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/[...] This is a classic problem in HTML development: The people doing the work are geeks with computer-science interests who do not understand, for example, newspapers, or screenplays, or, really, print publishing in general. In some obscure way, they disdain print publishing, as the Web is not print. Indeed it isn't, but print has structures the Web doesn't, and it doesn't have them because people like these refuse to acknowledge they exist or simply refuse to consider them.Note that while it certainly is true that I'm a geek who doesn'tunderstand many things outside my sphere of interests, it is _not_ truethat such concerns are being intentionally ignored here. I encourge you and anyone else who has desires for what HTML should do to speak up.Would you be open to hearing suggestions about how to add native video and video player support?(I have alot to say about that. And there's alot of people and companies who would find it very very useful. Rather than doing all the kludges that are in use today.) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] How not to fix HTML
Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ This is a classic problem in HTML development: The people doing the work are geeks with computer-science interests who do not understand, for example, newspapers, or screenplays, or, really, print publishing in general. In some obscure way, they disdain print publishing, as the Web is not print. Indeed it isn't, but print has structures the Web doesn't, and it doesn't have them because people like these refuse to acknowledge they exist or simply refuse to consider them. In the development of CSS, I actually think we erred on the side of traditional print-based documents rather than paying attention to computer science problems. For example, the existence of :first-line (which is a classic print-oriented feature) complicated the otherwise simple CSS1. CSS ignored, on the other hand, the interaction with programming languages (JavaScript) for too long. I think the CSS DOM would have been simpler if addressed in CSS2. Speaking for myself, I'm a print guy at heart. I publish newspapers [1], screenplays [2], novels [3] and specifications for print publishing in general [4][5]. All by way of HTML and CSS. [1] http://www.princexml.com/samples/ [2] http://people.opera.com/howcome/2006/ibsen [3] http://www.princexml.com/howcome/2006/slogans/slogans.pdf [4] http://www.w3.org/TR/css3-gcpm [5] http://www.w3.org/TR/css3-multicol -hkon Håkon Wium Lie [EMAIL PROTECTED] http://people.opera.com/howcome [EMAIL PROTECTED] http://www.princexml.com/howcome
Re: [whatwg] How not to fix HTML
Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html * Allow multiple uses of the same id/label in a form and suddenly it becomes possible to mark up multiple-choice questionnaires accessibly. Could you elaborate on this? I'm not sure how this would work with the DOM, but I'm sure there's a way of addressing the use case you have in mind. I believe the issue is with the way screen readers handle existing forms. The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. pGender: label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /p In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out Male and Female, it won't read out Gender:. In this specific case, that's probably not a major issue because male and female are fairly self explanitory, but there are many cases where it's not. There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset Because of the way screen readers work, they now read out Gender: Male and Gender: Female as they tab to each control. This example demonstrates this technique. http://www.alistapart.com/d/prettyaccessibleforms/example_3/ The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. There are a few possible ways to address this that I have thought of. 1. Allow labels to be associated with a group of form controls by referring to the control name. plabel group=genderGender:/label label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p (I know the for attributes aren't technically required here, but due to current screen reader limitations, they are) 2. Allow labels to be associated with multiple controls, using a space separated list of IDREFs (like the headers attribute in tables). plabel for=m fGender:/label label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p 3. Allow form controls to refer to additional labels. pspan id=genderGender:/span label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p 4. Same as #3, but allow the link from the label elements instead. pspan id=genderGender:/span label for=m info=genderinput type=radio id=m name=gender value=m Male/label label for=f info=genderinput type=radio id=f name=gender value=f Female/label /p I think #1 is the best of these options because it's more convenient to type a single name, than multiple IDs. Plus, if a new control gets added to the group, it's implicitly associated without having to update the for attribute with the new ID. I don't particularly like #3 and #4, but they were my first thoughts, so I listed them anyway. Start a Working Group For Web Accessibility, independent from the W3C, and write an alternative to WCAG2. In about 2 years, if the work you've done starts getting more traction than the W3C's work, then you'll get their attention and then they'll start fixing the WCAG work. Joe has already decided to take a similar approach with his WCAG Samurai. However, he's keeping it top secret. There's virtually no information about it and no way to participate or even keep track of the work without an invitation. http://alistapart.com/articles/tohellwithwcag2/#WCAG-documents:WCAGSamurai http://wcagsamurai.org/ -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Hello Lachlan,On 10/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-htmlThat link doesn't work. (I get a 404.)See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] How not to fix HTML
On Tue, 31 Oct 2006 03:01:47 +0600, Ian Hickson [EMAIL PROTECTED] wrote: Embed doesn't provide a fallback mechanism, and mixing parameters to the plugin, and attributes can be error prone, depending on the plugin, while object makes use of param. Sure but, everyone uses embed, and object doesn't (in practice) work that well really. Also, object is overloaded to do things like IFrames, and images, and plugins... having embed just for plugins would make it like img and iframe, the simple object for plugins. I belive that there should not be any special markup for plugins. The fact that the browser uses a plugin to display the movie, or image, or VR scene, or whatnot, is that browser's implementation detail. Some text-only browsers use external programs to display images, but there isn't a special markup which tells them to do so. I don't see why video clips should be any different. Because one of the goals of WHAT, as I perceive it, is to provide semantic markup for things that are currently marked up presentationally, I think that HTML 5 should encourage transition from the presentational EMBED (plugin content) to the semantic OBJECT (external subdocument) or even to more semantically fine-grained VIDEO, AUDIO etc. It doesn't mean that support for EMBED should be dropped: just like with FONT, there are many existing documents which use it, and there probably will be authors which continue using it despite its use being discouraged. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] How not to fix HTML
Charles Iliya Krempeaux wrote: http://lachy.id.au/log/2006/10/fixing-html That link doesn't work. (I get a 404.) Fixed, thanks. There seems to ge a bug WordPress that causes posts to get marked as private for some unknown reason. -- Lachlan Hunt http://lachy.id.au/
