Re: [whatwg] [html5] HTMLMapElement.images
Quoting Ian Hickson [EMAIL PROTECTED]: On 6/13/06, Anne van Kesteren [EMAIL PROTECTED] wrote: Before I forget about this hereby a proposal to give the HTMLMapElement interface a new (readonly) member called `images` or equivalent representing an HTMLCollection consisting of HTMLImageElement and HTMLObjectElement (and perhaps HTMLCanvasElement?) elements that use that image map definition. What's the use case? Basically finding the position of the associated image elements so that you can show popups and so more easily without hardcoding that a particular image belongs to that map and vice versa. https://bugzilla.mozilla.org/attachment.cgi?id=67731action=view ... has a nice example (works in Internet Explorer only). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] HTMLMapElement.images
Quoting Shadow2531 [EMAIL PROTECTED]: On 6/13/06, Anne van Kesteren [EMAIL PROTECTED] wrote: Before I forget about this hereby a proposal to give the HTMLMapElement interface a new (readonly) member called `images` or equivalent representing an HTMLCollection consisting of HTMLImageElement and HTMLObjectElement (and perhaps HTMLCanvasElement?) elements that use that image map definition. Do you want the INPUT element in the collection too? (because of type=image) Probably only when type=image, but yes. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: As a first step, I have tried to transform the TeX code used on Wikipedia (http://en.wikipedia.org/wiki/Help:Formula) into HTML5. This raises some issues, see http://xn--istein-9xa.com/HTML5/WikiTeX.pdf for all the details. I have tried to follow the current proposal, but I have probably misinterpreted a few things. Do correct me! Nice summary. Sorry for late reply, I was travelling. Quotes from Wikipedia TeX in HTML5 http://xn--istein-9xa.com/HTML5/WikiTeX.pdf 2.5 Big operators Remark: Is the following the intended use of under/over and opgrp? Yes. In fact I would be more appropriate to use the same markup for both and control rendering (under/over vs. sub/sup) via style sheets, but since it is impossible to have reasonable markup that admits both presentations (due to limited capabilities of CSS2.1) the only option is to allow both possibilities. Remark: The current proposal requires at least two rows and at least two columns. This makesitimpossibletodefineacolumnmatrixasamatrix(thevectorconstructisprobably meant to handle these), and completely impossible to define a row matrix This requirement can be safely removed, there are no XML or CSS motivated restrictions in this area. Remark: Presumably, the det element is intended to replace matrix here, but the ra- tionale seems unclear. Two kinds of brackets are not su?cient anyway, so the distinction would be purely semantical. Yes, destinction is purely semantical. fence left=solid right=solid matrixrowcellvarx/varcellvary/var rowcellvarz/varcellvarv/var/matrix/fence This will draw second fence around matrix (apart of that which already is part of matrix). If it is necessary to hardcode matrix fence styles in DTD then it would be more appropriate to add couple of attributes to matrix element, like you already proposed: Remark: Matrices tend to be surrounded by brackets of some sort. If technically feasible, it would therefore be convenient to indicate the left and right attributes directly on the matrix element. matrix left=solid right=solidrowcellvarx/varcellvary/var rowcellvarz/varcellvarv/var/matrix matrix fences will be considered as intrinsic part of matrix and will not requre extra fence element. cases varn/var/2,scopeif varn/varis even 3varn/var + 1,scopeif varn/varis odd/cases Should be cases casevarn/var/2,scopeif varn/varis even case3varn/var + 1,scopeif varn/varis odd /cases Remark: Should the scope node be optional? Maybe. Do you have some concrete examples in mind? 3.4 Other constructs ... vectorentryvara/varvarb/varentryvarc/var/vector Remark: Do we really want to mark up this as a vector? Note that vector includes fences. So what you need will probably require extra markup. ... Remark: Should we rather suggest an HTML table here? Either HTML table (in this case table should be allowed inside inline elements) or maybe separate element with inline-table functionality (table is probably better as some things like colspan, rowspan attributes can not be reproduced via XML+CSS). In fact it would be nice to more semantic markup here, but since it is hard to make such a markup comprehensive then maybe it is better to allow tables. The current proposal suggests the introduction of text-transform rules to facilitate the input of MAS characters and make HTML5 usable whilst plane 1 is still not fully imple- mented in browsers. This approach would seem to require 13 rules, and not only 3. The problem with some of them (script, bold script, Fraktur, bold Fraktur, double-struck symbols) is that there is no natural fallback for browsers that does not support plane 1. Others (sans-serif , sans-serif bold , sans-serif slanted, sans-serif bold slanted) can be added. Should they be added as a separate properties, or we should redefine current properties to behave appropriately when combined with font-family:sans-serif; (both make sense)? A font-family for Fraktur should probably be added to CSS anyway, as it would be useful not only for mathematics. Makes sense. On the other hand unlike generic font-families like serif, sans-serif and monospace Fraktur is used for limited number of Unicode characters. Also I am not sure whether Fraktur fonts are marked as such. Remark: The current attributes on the fence element do not permit constructions like ]0, 1/2] Such a constructions can be added to proposal if necessary. Problem: These delimiters /*ed. mainly arrows*/ do not seem to be supported in current proposition. The problem is related to fallback CSS rendering. Remark: Explicit indication of delimiter size not supported One can add values like medium, large, x-large, xx-large to current proposal. Personally I like ISO 12083 sizeid attribute that sets size of fence equal to size of subexpression with id specified by sizeid attribute. It does not work however in
Re: [whatwg] Mathematics in HTML5
Oistein E. Andersen wrote: This issue [font selection] belong to presentational layer and has to be addressed on CSS side (there are no problems on XSL and/or DSSSL side as one can make appropriate transformations). I am not so sure about that. In fact I am not sure either. The difference between bold, italic and script can be just as important as the distinction between base, superscript and subscript. Explicit mark-up is provided in ISO-12083, MathML and TeX, among others, and mathemtical characters (which we would like to use, but cannot -- yet?) have been added to Unicode because of their semantical importance. If the removal of class attributes is supposed to preserve meaning, then it does not seem right to use this very attribute to encode different math alphabets. Yes, one can add special attribute for this purpose. Do you have any concrete propopsal? [classes:] vector or Hilbert-vector [or] ket. I would leave [the choice] to authors until that a generic semantic markup was achieved, proved to be consistent and powerful and then used by authors. With all the different concepts and notational conventions that exist in different scientific fields and mathematical disciplines, no such thing as a generic semantic mark-up is likely to appear any time soon. I tend to believe that you agree. Agree. However those who are interested in generic semantic mark-up will have access to semantic layer of current proposal via set of predefined attributes (currently role and mprofile, extra attributes may be added after consultations with people invloved in projects like OpenMath, CanonML etc.) -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
[whatwg] On accessibility
Hi, I've spoken to a person who is blind about HTML5 and accessibility. I thought I'd send some of his thoughts to the list. He is in favor of the new nav and article elements indicating the navigation section of the page and what is the main content: yeah that'd be excellent, if screen readers would pick up on this somehow. because really my main goal when I get to the front page of a web site, if I've not been there before, is to get to the main content and see what that site's about, what's on that site, etc. My second goal is then to get to the navigation to find a section I'd like to navigate to. He says that HTML5 shouldn't drop the longdesc attribute, because it is useful for people using screen readers. longdesc is a long description, which is what you're wanting to give. alt is alternative text, which is just to give me a basic idea of what's there. i don't want to read a big paragraph for an image unless I really wan to know what's there. He also says that he accesskeys shouldn't be dropped. I love accesskeys, despite anything bad people have said about them, they're great. very convenient. if I notice an accesskey on a site I visit often, I make use of it. I would disagree with [HTML5 dropping accesskeys] more than longdesc. accesskeys, are really useful, and again I tend to use them whenever I come across them. it's a shortcut to get to where you want to go, instead of having to search for it. Regards, Simon Pieters
Re: [whatwg] On accessibility
Simon Pieters wrote: I've spoken to a person who is blind about HTML5 and accessibility. I thought I'd send some of his thoughts to the list. ... He also says that he accesskeys shouldn't be dropped. Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. http://www.wats.ca/show.php?contentid=43 If implementations can be modified so that accesskeys do not interfere with existing shortcut keys, then that's great. Perhaps they could offer a kind of web-apps mode where all Alt+[key] combinations are safe to be used by the web page, and then another mode where they retain their normal browser functions. But until something like that happens and proves successful, accesskeys should not be retained. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] On accessibility
On Thu, 15 Jun 2006 08:09:43 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. What Opera does makes sense. Maybe it should be standardized. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] On accessibility
On Jun 14, 2006, at 9:47 PM, Alexey Feldgendler wrote: On Thu, 15 Jun 2006 08:09:43 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. What Opera does makes sense. Maybe it should be standardized. ... What Opera does is indeed very cool, but it's quite possible that another browser could come up with something even cooler. And in this area there is very little benefit from interoperability, so I don't see any point in standardizing it. It would be like standardizing on vi. (Or emacs.) (There is actually *harm* from interoperability for accesskey=, from Web authors cluttering pages with instructions on how to use access keys because they're so non-obvious -- instructions that may be incorrect for some platforms, depending on how they're worded, and that are irrelevant for non-interactive UAs like Google.) -- Matthew Paul Thomas http://mpt.net.nz/
