Re: [whatwg] Issues concerning the base element and xml:base
On Wed, 30 May 2007, Jonas Sicking wrote: The latter is the option I'm following for now. Note that browsers all do _different_ things for target= than for href=. The spec has made them act the same for now. I'm not sure this is workable, we'll have to see when the browser vendors try to get this interoperable. I can't imagine that it's a huge issue given that the browsers are so far from each other in terms of what they do here. I'm going to do a study of some subset of the Web to see how common this is (at least the static case; I can't really do much about the scripted case). I don't think this is a good solution actually. In general, I think it's good to always make the DOM reflect the behavior of the document. I.e. it shouldn't matter how you arrived to a specific DOM, be it through parsing of an incoming HTML stream, or by using DOM-Core calls. Whenever we make an exception for that rule I think we need to have a good reason for it. I think you misread what I wrote. Right now, there's no magic involved here. When you said the latter is the option I'm following for now I thought you referred to and Firefox and IE7/Win don't change any links. Is that not the case? Looking at the spec it doesn't mention anything special regarding DOM mutations at all, so that would indeed make me think that links are changed if a base element is inserted at the top of the head using the DOM. I'm not sure what I meant by latter anymore. Indeed, in the dynamic case, all relative links get reresolved when the first base href= changes. What I suggest is that we make the first or last base element in the head be the one that sets both the base target and the base href for the document (modulo all special handling needed when bases appear in the body, described below). While this is not what IE or Firefox does today, I doubt that it'll break enough pages to stray from the act-like-the-DOM-looks principal. Right now the href= is from the first and the target= is from the last, but other than that that's what the spec says. Why is the fact that the last target is the one used only defined in a Note? Or am I missing it somewhere else? It's defined in the Following hyperlinks section. Also, if we're going to be inconsistent in how current browsers and web pages handle multiple bases, why not simply use the first base for both href= and target=? Done. HOWEVER, having said that, this is a tiny minority of pages. According to a study I did of over 100,000,000 pages, 0.036% of pages have more than one base href= element (ignoring those that specify the same href= value more than once). With base href=, you can get 404s, but in practice IE7 is already doing that, and it doesn't seem to have affected adoption. Anecdotely, most of these pages use absolute URIs, which might explain it. It's much easier for IE to get away with breaking pages, mostly because many people use IE as the yard-stick. Sure. But once IE has broken the pages, it's easier for everyone else to follow... 0.06% of pages have more than one base target= element (again ignoring duplicates). With base target=, the worst that can happen from the user's point of view is that links will open in a new page instead of on the same page, and in practice even that's not likely, since (anecdotely) most pages with base target= simply alternate between different names. What do you think? I would be hesitant to drop support for multiple bases in firefox actually. Implementation wise it was very easy to implement, and it is known that many pages out there break, though the percentage is small, there are a lot of pages on the internet. It might be something we could restrict to quirks mode pages though, that's not a bad idea at all. Right now the spec requires no multiple-base support in all modes. As a datapoint -- several of the pages I had found as being users of multiple base elements back in May are now using only one base. This is how it stood back in May (using a sample of several hundred thousand pages taken mostly from the more popular sites); number of unique URIs in base href attributes as a percentage of all pages parsed: 0: 93.7% 1: 6.31% 2: 0.0308% 3: 0.00105% 4: 0.00197% This is how it stands as of today (using the same sampling method): 0: 94.1% 1: 5.93% 2: 0.0215% 3: 0.000928% 4: 0.000288% (All numbers rounded to three significant figures.) So it seems the trend is in the right direction. Also, note that most of the pages I examined personally back in May (sampled from the pages that contribute to the above statistics, biased towards pages that use base href the most and that have the most relative URIs in links and images) were either pages that seemed unlikely to be widely used (e.g. spam pages, or aggregates
Re: [whatwg] Issues concerning the base element and xml:base
On 07/08/07, Ian Hickson [EMAIL PROTECTED] wrote: This is how it stood back in May (using a sample of several hundred thousand pages taken mostly from the more popular sites); number of unique URIs in base href attributes as a percentage of all pages parsed: 0: 93.7% 1: 6.31% 2: 0.0308% 3: 0.00105% 4: 0.00197% This is how it stands as of today (using the same sampling method): 0: 94.1% 1: 5.93% 2: 0.0215% 3: 0.000928% 4: 0.000288% (All numbers rounded to three significant figures.) That rounding seems quite misleading - if I haven't forgotten how to do statistics, and if the details I am forgetting are not critical ones, and if I'm not misinterpreting how you collected the data, then the samples are independent and from a binomial distribution that can be approximated as a normal distribution with standard deviation sqrt(n*p*(1-p)), and if assuming n=100,000 and guessing p from the data then the 95%-confidence (+/- 2 s.d.) ranges are something like: 0: (93.7 +/- 0.15)% 1: (6.3 +/- 0.15)% 2: (0.03 +/- 0.01)% 3: (0.001 +/- 0.002)% 4: (0.002 +/- 0.003)% and 0: (94.1 +/- 0.15)% 1: (5.9 +/- 0.15)% 2: (0.02 +/- 0.01)% 3: (0.001 +/- 0.002)% 4: (0.0003 +/- 0.001)% (though the normal approximation breaks down in the = 0.002% bits), so you can't determine anything about changes in frequency beyond the zero/one cases. -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Looking at menus in HTML5...
- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: Andrew Fedoniouk [EMAIL PROTECTED]
Cc: WHAT WG List [EMAIL PROTECTED]
Sent: Tuesday, August 07, 2007 1:14 AM
Subject: Re: [whatwg] Looking at menus in HTML5...
On Mon, 6 Aug 2007, Andrew Fedoniouk wrote:
Pay attention on Third option - submenu. It contains additional
markup and/or styling.
Assuming you mean for the boldened letters to represent the
accelerator key, the idea is that you don't have to give them at all,
the user agent will determine the optimal accelerators.
That was just an example.
I mean that either you allow all menu items to have arbitrary markup or
all of them should have plain text only model (so be an option).
All the menu item labels are pure text. See the definitions in the section
on how commands are defined (3.18.5. Commands). Any included markup gets
flatted out and is really only allowed for fallback purposes.
Pure text? Why?
As an example see first image ont the right at:
http://en.wikipedia.org/wiki/Pie_menu
There are many cases when menus are not just flat lists of items.
Examples: Start menu in Windows contains as menu items as buttons,
see: http://en.wikipedia.org/wiki/Start_Menu
And gnome:
http://reverendted.wordpress.com/2006/06/17/show-me-that-new-gnome-main-menu/
and KDE:
http://photos1.blogger.com/x/blogger/938/4204/1600/471459/menu.png
Simplistic flat menus is an outdated concept in UI - limitations of initial
implementations
when there were simply no way to define more or less rich content in
resource files.
All modern OSes use more flexible layouts of menus.
In principle menu is a short living window running so called
mouse-modal-loop. There is no technical limitations to limit
its content by just flat lists. Especially in context of Web Application
that supposed to mean thing that have modern and rich UI.
In real UI there are cases when menu even contains input elements:
http://terrainformatica.com/htmlayout/images/css-menus.png - so may have
arbitrary markup.
The current spec supports checkbox and radio button menu items; further
types are quite rare and I don't think we should support them in this
version of the specification. (We can always extend the specification at
some later time.) (The only GUI I am aware of that condones text fields in
a menu would be the graphical RiscOS shell, and the other UI concepts
shown in that screenshot are extremely rare and we could probably get away
with never supporting them.)
As you may see above, Windows XP/Vista, Gnome and KDE4 all use
rich menus. So it is not RiscOS only.
And in modern web applications typical implementation of menu compnents
provide rich menu constructions.
Example
http://www.telerik.com/demos/aspnet/Menu/Examples/Overview/DefaultCS.aspx.
So I would not restrict menus in the way it is done in HTML5 now.
It is enough that we have so limited select.
Personally I think that menu functionality is a part of CSS
specification, something like:
menu { position: popup }
should allow to define menus as popup elements if needed.
Menu items even can be organized as a table (td role=menu-item) :
http://www.terrainformatica.com/htmlayout/images/popupdemo.png
IMHO that's a separate widget, not a context menu. I would expect such a
UI to be built using XBL or a new widget in a future version of HTML.
How you would achieve this with the @label?
You don't need to bolden the letters, so it all Just Works.
Sorry but I am not so optimistic. You cannot build optimal shortcut
system deducing only captions. Think about cut/copy/paste/select-all
menu items written in different languages.
I'm just talking about the menu item mnemonics, not the shortcut keys. The
shortcut keys are part of the bigger accesskey problem for which we don't
even have the start of a solution yet. Whatever solution we find for
accesskey will just be folded into the command and menu features.
Mnemonics in menu items is a very old concept. I doubt that people
are using them for selecting menu items. They used to be actual for
UI scripting/automation when sending of keystrokes was the only
way to activate some function/command from the code.
Do you know anybody who is using mnemonics for menu item activations
these days? Especially in web apps that are primarily occasionally used
and highly dynamic things - you literally cannot remember all keystroke
sequences for particular functions in all sites you are visiting. In
contrast
rich menus with inline descriptions and proper organization will help
you significantly more to get what you need in application that you use
say at the end of the month to do your online banking or so.
Andrew Fedoniouk.
http://terrainformatica.com
Re: [whatwg] Issues concerning the base element and xml:base
On Tue, 7 Aug 2007, Philip Taylor wrote: That rounding seems quite misleading - if I haven't forgotten how to do statistics, and if the details I am forgetting are not critical ones, and if I'm not misinterpreting how you collected the data, then the samples are independent [...] The samples are not independent. In fact they have a high degree of overlap. and from a binomial distribution that can be approximated as a normal distribution with standard deviation sqrt(n*p*(1-p)), and if assuming n=100,000 [...] Sorry, I meant in the order of 100 million, not 100 thousand. My bad. and guessing p from the data then the 95%-confidence (+/- 2 s.d.) ranges are something like: I don't know if the rest of it is correct or not (what distribution the data follows, etc). The fact that I haven't done these analyses is one reason why I'm skeptical about publishing this data more officially. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Looking at menus in HTML5...
On Tue, 7 Aug 2007, Andrew Fedoniouk wrote:
Pure text? Why?
With HTML5 we're following a design principle of not biting off more than
we can chew at once -- so the initial design is intended to be very
conservative.
As an example see first image ont the right at:
http://en.wikipedia.org/wiki/Pie_menu
The current HTML5 design supports pie menus -- the menu should be
presented in whatever fashion is considered native to the OS. If the OS
uses pie menus, then that's what should be used. Nothing in the HTML5 spec
requires that the menu be your typical vertical list of items.
There are many cases when menus are not just flat lists of items.
Examples: Start menu in Windows contains as menu items as buttons,
see: http://en.wikipedia.org/wiki/Start_Menu
And gnome:
http://reverendted.wordpress.com/2006/06/17/show-me-that-new-gnome-main-menu/
and KDE:
http://photos1.blogger.com/x/blogger/938/4204/1600/471459/menu.png
These aren't context menus, so they're not really in scope for this
feature.
As you may see above, Windows XP/Vista, Gnome and KDE4 all use rich
menus. So it is not RiscOS only.
The three menus you mention above are all examples of a specific OS
launcher menu, they're not context menus. The feature under discussion is
currently intentionally limited in scope to just context menus.
And in modern web applications typical implementation of menu compnents
provide rich menu constructions.
Example
http://www.telerik.com/demos/aspnet/Menu/Examples/Overview/DefaultCS.aspx.
Indeed, colour selection is something we might well do in a future
version, as are menu buttons or toolbars with drag-down button sets.
(Everything else on that page can already be done with the spec as is.)
So I would not restrict menus in the way it is done in HTML5 now.
It is enough that we have so limited select.
While your enthusiasm for flexibility is commendable, we are intentionally
limiting the speed at which we add features to HTML5 to prevent feature
creep. Feature creep is often the cause of poor quality implementations.
We have to move slowly so that we can take into account implementation
experience from multiple vendors (especially those with significant market
share), and so that we can make sure we are addressing the most desired
features instead of only the most unusual ones.
Personally I think that menu functionality is a part of CSS
specification, something like:
menu { position: popup }
should allow to define menus as popup elements if needed.
Indeed, such a feature might well be necessary to support menus and popup
controls in XBL. I recommend bringing this up to the CSS working group.
I'm just talking about the menu item mnemonics, not the shortcut keys.
The shortcut keys are part of the bigger accesskey problem for which
we don't even have the start of a solution yet. Whatever solution we
find for accesskey will just be folded into the command and menu
features.
Mnemonics in menu items is a very old concept. I doubt that people are
using them for selecting menu items.
That's quite possible, but it doesn't affect the specification, since the
mnemonics are simply left up to the implementation, which can simply
ignore them if they decide they are not necessary.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Looking at menus in HTML5...
- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: Andrew Fedoniouk [EMAIL PROTECTED]
Cc: WHAT WG List [EMAIL PROTECTED]
Sent: Tuesday, August 07, 2007 1:52 PM
Subject: Re: [whatwg] Looking at menus in HTML5...
On Tue, 7 Aug 2007, Andrew Fedoniouk wrote:
Pure text? Why?
With HTML5 we're following a design principle of not biting off more than
we can chew at once -- so the initial design is intended to be very
conservative.
I think that
menu type=context-menu
liCopykbdCtrl-C/kbd/li
/menu
is conservative enough as it allows me to define typical menus.
All modern UAs have their own implementation of menus
so they already can chew menu items with markup and styling.
Otherwise menu should not use li but option or so.
But this will not be backward compatible.
As an example see first image ont the right at:
http://en.wikipedia.org/wiki/Pie_menu
The current HTML5 design supports pie menus -- the menu should be
presented in whatever fashion is considered native to the OS. If the OS
uses pie menus, then that's what should be used. Nothing in the HTML5 spec
requires that the menu be your typical vertical list of items.
There are many cases when menus are not just flat lists of items.
Examples: Start menu in Windows contains as menu items as buttons,
see: http://en.wikipedia.org/wiki/Start_Menu
And gnome:
http://reverendted.wordpress.com/2006/06/17/show-me-that-new-gnome-main-menu/
and KDE:
http://photos1.blogger.com/x/blogger/938/4204/1600/471459/menu.png
These aren't context menus, so they're not really in scope for this
feature.
As you may see above, Windows XP/Vista, Gnome and KDE4 all use rich
menus. So it is not RiscOS only.
The three menus you mention above are all examples of a specific OS
launcher menu, they're not context menus. The feature under discussion is
currently intentionally limited in scope to just context menus.
Do you have definitions on what is context menu and what is not?
Do you have any examples of exisiting web applications that will
benefit significantly from having that flat puristic context menus?
Almost all real cases when context actions are needed are perfectly
handled by side bars with list of links. So why bother?
So where this context menu feature request comes from?
And in modern web applications typical implementation of menu compnents
provide rich menu constructions.
Example
http://www.telerik.com/demos/aspnet/Menu/Examples/Overview/DefaultCS.aspx.
Indeed, colour selection is something we might well do in a future
version, as are menu buttons or toolbars with drag-down button sets.
(Everything else on that page can already be done with the spec as is.)
BTW: Everything there works already without any HTML5.
I believe that HTML5 goal is to provide more or less
generic solution that can serve as simple menus *and*
cover the whole class of popup elements and lightweight
dialog needs.
Otherwise we will end up with spending rest of our life
adding that endless menu, rich-menu, popup,
dialogue,monologue, novel, poem,
haiku, whatever
So I would not restrict menus in the way it is done in HTML5 now.
It is enough that we have so limited select.
While your enthusiasm for flexibility is commendable, we are intentionally
limiting the speed at which we add features to HTML5 to prevent feature
creep. Feature creep is often the cause of poor quality implementations.
We have to move slowly so that we can take into account implementation
experience from multiple vendors (especially those with significant market
share), and so that we can make sure we are addressing the most desired
features instead of only the most unusual ones.
It is not an enthusiasm but rather frustration of where this thing is
moving.
As I said, proposed menu is not a solution. Just a cosmetic and
limited feature that will solve some pretty small number of cases. If any.
In any case I would like to know examples of existing web applications
that such non-styleable menus.
Personally I think that menu functionality is a part of CSS
specification, something like:
menu { position: popup }
should allow to define menus as popup elements if needed.
Indeed, such a feature might well be necessary to support menus and popup
controls in XBL. I recommend bringing this up to the CSS working group.
XBL is using primitives of DOM and CSS.
So yes, if you will be able to define this in HTML/CSS then
you can use XBL(Gecko) or HTC (IE) or some other
technology of this kind.
Andrew Fedoniouk.
http://terrainformatica.com
Re: [whatwg] Looking at menus in HTML5...
On Tue, 7 Aug 2007, Andrew Fedoniouk wrote: On Tue, 7 Aug 2007, Andrew Fedoniouk wrote: Pure text? Why? With HTML5 we're following a design principle of not biting off more than we can chew at once -- so the initial design is intended to be very conservative. I think that menu type=context-menu liCopykbdCtrl-C/kbd/li /menu is conservative enough as it allows me to define typical menus. Indeed, as I mentioned earlier the shortcut key feature is currently missing but will be added when we figure out the solution for the more general accesskey issue. All modern UAs have their own implementation of menus so they already can chew menu items with markup and styling. The intent is to allow implementations to use native OS menu support. Otherwise menu should not use li but option or so. But this will not be backward compatible. Well, as currently specced we can use select and thus options in menus already. As you may see above, Windows XP/Vista, Gnome and KDE4 all use rich menus. So it is not RiscOS only. The three menus you mention above are all examples of a specific OS launcher menu, they're not context menus. The feature under discussion is currently intentionally limited in scope to just context menus. Do you have definitions on what is context menu and what is not? Sure, it's the type of menu you get (for instance) when control-clicking on the Mac or right-clicking on Windows, as opposed to the kind of menu you get from a menubar, menu button, or OS application launchers. Do you have any examples of exisiting web applications that will benefit significantly from having that flat puristic context menus? Web applications widely have hacks for context menus today. For example, Google Maps and Live Search maps have simple context menus. Today they have to have non-native implementations that don't really work well and that interfere with the browser's features. So where this context menu feature request comes from? It's a frequent request from Web app developers. BTW: Everything there works already without any HTML5. Excellent! I believe that HTML5 goal is to provide more or less generic solution that can serve as simple menus *and* cover the whole class of popup elements and lightweight dialog needs. Nope, that isn't the goal. We're aiming at 80% with the intent to keep the basic language simple and approachable. Otherwise we will end up with spending rest of our life adding that endless menu, rich-menu, popup, dialogue, monologue, novel, poem, haiku, whatever For things that HTML can't handle, authors have to fall back on CSS and JS, and (in the future) XBL, as I mentioned. I don't think we will ever need to specifically have a haiku element, for instance. While your enthusiasm for flexibility is commendable, we are intentionally limiting the speed at which we add features to HTML5 to prevent feature creep. Feature creep is often the cause of poor quality implementations. We have to move slowly so that we can take into account implementation experience from multiple vendors (especially those with significant market share), and so that we can make sure we are addressing the most desired features instead of only the most unusual ones. It is not an enthusiasm but rather frustration of where this thing is moving. As I said, proposed menu is not a solution. Just a cosmetic and limited feature that will solve some pretty small number of cases. If any. I would argue that what we have in the spec now solves a good 80% of all needs for menus and tool bars. I don't think most people need pie menus, application launchers, complex markup in menus, etc. In any case I would like to know examples of existing web applications that such non-styleable menus. I gave two earlier; Google Docs and Spreadsheets is another. Context menus that are non-styleable are used in almost all desktop applications, so any Web analogue to desktop applications could well want to use one. We frequently get requests for how to do this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Where did the rev attribute go?
This e-mail consists of replies to a few e-mails on the subject of links and link relationship types. No changes were made to the spec in response to these e-mails; if you reply, please indicate if you think something needs to change in the spec. Thanks! On Sat, 8 Jul 2006, Charles Iliya Krempeaux wrote: But, if the intent [of removing 'rev'] to really get rid of confusion then There's actually 2 things I noticed confuse people. #1: That the label you pick for the rel (or rev) needs to be a noun. (I do understand why... at least I think I do... so that you can use the same label in the class attribute. But it makes things difficult for some people.) As others noted, the label you should pick for rel should be taken from a specific set of labels defined in a specification (either HTML4, or HTML5, or a Microformat spec, or some other extension specification). So the noun aspect isn't a source of confusion as far as I can tell. It may be that people don't know you shouldn't just arbitrarily make up now names, though. #2: That rel (and rev) represent a relation between the two. Often people seem to want to classify what's at the end of the href. (Instead of specifying a relation.) Perhaps a new attribute is needed. Perhaps hrefclass. class on an a element can be used for this, IMHO. On Tue, 11 Jul 2006, Charles Iliya Krempeaux wrote: Let's say in a page, I have the following HTML code... li class=xoxo shows lia rel=show href=http://show.example.com/;Example IPTV Show/a/li lia rel=show href=http://show2.example.com/;Another Example IPTV Show/a/li /li The semantics here are The class-xoxo (on the li) says that I'm giving a list here. I assume you meant to use an ol on the outside, not an li. And in that case, it's the ol that says that you're giving a list, the xoxo class isn't necesarry to give the list semantic. And the class-shows says this thing is/has shows. (So basically, I'm listing shows.) This isn't a strong semantic (a random person who doesn't know you wouldn't necessarily know that's what your class meant), but it can be a convention you use within a particular community, sure. The rel-show inside the list of shows, says what's at the end of the href is a show for the list of shows. You could easily use class on the a element for this, without risking a clash with a future value introduced in (say) HTML6 for slideshow links. It would be as solid, semantically. If you wanted to go further, you'd have to define a specification for your rel or class show value. Your specification could then include the rest of your description: So,... if you go to the URL in the href, you get a whole HTML page with all sort of stuff in there. But what is the show? The whole page? Just part of it? Well, I then search the page for class-show. (I look for something inside the page with a class with the same token/name use in the rel that linked there.) If I find (just) one, then great, that's probably what I want to concentrate on. (The other parts of the page are probably irrelevent.) If not, I'll probably have to concentrate on the whole page. (This is the idea of opaque semantics that I was talking about before.) Does that clear it up? (This is what I imagined the developers of these things originally thought up.) I suggested hrefclass because we already have things like... lang and hreflang. It just seemed to follow the same style. (Since this seems to be just like the class attribute, expect we are applying it to what is at the end of the href... so hrefclass.) I don't really understand why you can't just apply it to the link itself (i.e. use class). On Tue, 11 Jul 2006, Charles Iliya Krempeaux wrote: Perhaps it's a poor example. But what I've gotten from the specs is that the rel attribute can be used in this way. Could you check the HTML5 spec and let me know if it can still be interpreted this way? For an example that's gained some popularity, look at hCard. http://microformats.org/wiki/hcard People wanted to semantically denote contact info. So they choose a set of class names to use (to do this) and some rules about them. Creating the standard is a somewhat arbitrury process. And requires humans to do it. Although with opaque semantics, like the rel name matching the class name, you don't need a human intervention to parse much of it. Does what I'm saying make sense? Or should I explain it more? I'm not convinced there's really a use case for making this automated to the level that you describe. It seems best to stick to having specifications for the cases that actually have uses. Alot of this is done for the benefit of machines (like browsers, spiders, search engines, etc). Right now, everything is done for the benefit of humans. The machines are just tools. But getting back to one things you said... it is NOT always the
Re: [whatwg] Image maps: should we drop a coords=?
On Thu, 1 Sep 2005, fantasai wrote: Ian Hickson wrote: On Mon, 11 Apr 2005, Anne van Kesteren wrote: Yup, it is indeed nice; if image maps had been designed that way from the start it would make sense. But it's not _that_ much nicer than area, which we could define as allowing: object data=foo usemap=#foo map id=foo ul liarea coords=... href=...a href=../a ... ...which isn't much worse, and has the very important benefit of actually working in IE6. And the perhaps less important disadvantage that it's impossible for a machine to warn against the lack of alt text. With both area and a in HTML 4, the spec was able to require 'alt' attributes on area, because, given a coords=... to fill the mixed coords and fallback role, area was not intended to be used in conjunction with other fallback content. In what you're proposing, area also takes the role of a coords=... and therefore takes no 'alt' attribute. The end result is, there's no way to know if the author actually provided alt text or is just throwing area into a mix of random block content. Indeed. Not a huge problem, IMHO. Another thing to think about: afaict, the HTML 4 spec doesn't say whether or how the image map coordinate system scales when an image is stretched or shrunk via CSS. Fixed in HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] HTMLMapElement.images
On Sat, 1 Jul 2006, dolphinling wrote: Anne van Kesteren wrote: 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. Can you even have an image map on an input type=image ? You can in HTML4, Firefox, and Opera (and now HTML5). You can't in IE and Safari. Should we drop it? My research indicates there's an insignificant number of pages with usemap= attributes on input type=image elements (on the order of 0.008%). Anyway, I've added the attribute Anne suggested to the map element. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] map id=
On Sat, 6 Jan 2007, Anne van Kesteren wrote: I think that besides supporting map name= it should also support map id= to be referenced from usemap (not with an IDREF, but with an URI, mind you). This is compatible with what Opera does in both HTML and XHTML, Firefox in XHTML and Internet Explorer in HTML. The spec requires this. (Not sure when I added it, though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
