Re: [whatwg] map id=
On Wed, 08 Aug 2007 20:21:00 +0200, Michael A. Puls II [EMAIL PROTECTED] wrote: Just wan to be sure: Even though id is required, name is allowed on map. Correct? No. name is currently not allowed (but I have suggested we change to name instead of id [1]). (It currently needs to be for Safari and Firefox in text/html or image maps won't work (even on trunk versions) Indeed. As for case: [Opera] match for id or name is case-insensitive regardless of mime type. [Firefox and Safari] application/xhtml+xml match for id is case-sensitive text/html match for name is case-insensitive [IE6] match for name or id is case-insenstive. So, it seems it might have to be case-sensitive for xhtml5 (since other things are case-sensitive in xml) and case-insensitive for html5. (Unless there's no need to be case-sensitive for XHTML5. If so, then Opera's way would be cool.) I don't see any need for it to be case-sensitive for XHTML5. :-) [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010975.html -- Simon Pieters
Re: [whatwg] Text selection in IFrames
If I have a text selection in an iframe and select text or click on any element in the parent document the browsers behave differently On Tue, 17 Jul 2007, Fabian Jakobs wrote: What is the desired behavior in this case? On 8/1/07, Ian Hickson [EMAIL PROTECTED] wrote: It depends on the platform's conventions. It's not really an interoperability issue as far as I can tell. Not an interoperability issue? One of the main benefits of HTML has been it's device-independence. Ideally, a page should look and act the same in every browser on every platform. Frankly, I don't see an application for using user-selected text, but if a script requests the selected text, it should be clear what the script is getting. Daniel Brumbaugh Keeney Devi Web Development [EMAIL PROTECTED]
Re: [whatwg] Where did the rev attribute go?
I assume that you have too much current work to remember what you have written and why. You suggested that using class names as semantic attributes requires some central authority to publish a specification of the microformat in order that the robots are able to find out the meaning of the class names used. I disagreed because I think the meaning can be inferred from the names themselves. And no, this is not a request for a change. Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, August 09, 2007 1:23 AM To: Křištof Želechovski Cc: 'WHAT Working Group Mailing List' Subject: Re: [whatwg] Where did the rev attribute go? On Wed, 8 Aug 2007, Křištof Želechovski wrote: Automatic: class=A-N means A N. No spec needed. E.g.: class=red-herring means a red herring, and class=important-news means some important news. I don't understand this post; please let me know if it was requesting a change to the spec (ideally by explaining what is wrong with the spec that needs changing). Cheers, -- Ian Hickson
Re: [whatwg] Looking at menus in HTML5...
I had motoric disabilities in mind. The simplest way to generate menu item mnemonics is to do it incrementally, as in autocompletion. It requires the items to have distinct prefixes so having both Save and Save as... is unacceptable. Another possibility is to use the first letter if it is unique, otherwise repeat pressing the first letter until you arrive at the item you need and press Enter. It works if the menu is relatively short. And the Polish term for Select all is Mark all. It is not a translation but it is commonly used. It was used for the English interface in ancient text editors, e.g. ChiWriter. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Fedoniouk Sent: Wednesday, August 08, 2007 10:08 PM To: Křištof Želechovski; 'Ian Hickson' Cc: 'WHAT WG List' Subject: Re: [whatwg] Looking at menus in HTML5... I imagine keyboard mnemonics are especially important for people with disabilities. - I wouldn't say so. Ian propose to generate mnemonics automatically as far as I understand. So to be able to use mnemonics someone should read it first and find that mnemonic letter. By default and without proper (ususally custom) styling this is extremely hard to do for people of some groups. And yet: how you would generate mnemonic for, say, SELECT ALL (ru: ВЫБРАТЬ ВСЁ, pl: WYBRAĆ CAŁY or so) Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] Looking at menus in HTML5...
Please note that it indicates the text to entered and not the keys to press. Of course this is somewhat inconsistent with the tag name since the text need not come from the keyboard at all, e.g. it can be pasted. Your hint suggests that the user should enter text Ctrl-C. Happy coding, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Fedoniouk Sent: Wednesday, August 08, 2007 9:46 PM To: Křištof Želechovski; 'Ian Hickson' Cc: 'WHAT WG List' Subject: Re: [whatwg] Looking at menus in HTML5... I would insist that following menu type=context-menu liCopykbdCtrl-C/kbd/li /menu 1) is semantically correct construction as KBD: Indicates text to be entered by the user. [1]
Re: [whatwg] Text selection in IFrames
On Thu, 9 Aug 2007, Devi Web Development wrote: Not an interoperability issue? One of the main benefits of HTML has been it's device-independence. Ideally, a page should look and act the same in every browser on every platform. Frankly, I don't see an application for using user-selected text, but if a script requests the selected text, it should be clear what the script is getting. ...and it is -- the script will get whatever the user selected. But different platforms have different conventions (e.g. on X the selection will be cleared if another selection is made in another application) and it is not our place to dictate UI. It doesn't make any difference to well-written applications what the conventions are. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text selection in IFrames
At 09:37 -0500 UTC, on 2007-08-09, Devi Web Development wrote: [...] On 8/1/07, Ian Hickson mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: It depends on the platform's conventions. It's not really an interoperability issue as far as I can tell. Not an interoperability issue? One of the main benefits of HTML has been it's device-independence. Ideally, a page should look and act the same in every browser on every platform. Not at all. Ideally a page should look and behave such as is most useful to the user. It might confuse *me* to see multiple selections in a document, but if that's the convention someone else is used to, why confuse him by breaking that? Or why should I confuse you by forcing my convention upon you, when that might conflict with what you're used to? Not to mention all those looks and behaviours that are common in one browsing environment, but simply impossible in another. Frankly, I don't see an application for using user-selected text, but if a script requests the selected text, it should be clear what the script is getting. I would assume that an environment that shows all selections in all iframes is something the user is used to; he'll be fully aware which frame is the active one; and the UA will probably hand the active frame's selection to a script, when the script asks for 'the' selection. (I'm not a javascripter; this just seems logical to assume.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about an event for when the #fragid changes
On Tue, 28 Feb 2006, Loune wrote:
I don't know if this has been addressed or not, since I only briefly
scanned the spec. Hopefully, I didn't write this for nothing :) This
relates to the handling of anchors in URLs:
A common argument or complaint against AJAX is that it renders the back
and forward buttons useless and thereby interrupting the normal flow of
browsing. It is also impossible to bookmark the state of the page [due
to the URL remaining the same]. Normally, navigating to a new URL will
result in the browser performing a new request to the server, but there
is one exception to that - which is invoking an anchor via # suffix.
Traditionally, the suffixes are used to jump to the location which the
invisible anchor is located.
My proposal is to extend anchoring into a scriptable feature with the
addition of the anchor DOM Event. The anchor event will be fired every
time the page URL stays the same but the anchor suffix of the URL
changes. This basically includes:
- Back and Forward navigation of anchors
- Manually typing a URL/Loading from a bookmark
This is not unlike typical GET query strings where the portion after ?
are variables passed to the same script on the server, with the main
difference here being that this acts as a client-side query string. The
anchor event will be used to perform an action by the JS on the same
page.
What the event interface could look like: [...]
Flow of events:
- When the page is loaded, and an anchor event listener exists, the
anchor event will be fired after the load event. If there is no anchor
in the URL, the event.anchorName property will be an empty string.
- When an anchor link is clicked, the anchor event listener (if exists)
will be fired
- The event handler can get the name of the anchor via event.anchorName
(which will contain the string after the hash)
- If the return value from the handler is true, the traditional form of
operation (the jumping to the anchor) will occur next; otherwise, that
step is skipped.
- The UA should act as if the navigation has gone forward a page (add
history, etc).
- If the user navigates back and the previous page happens to be the
same page but a different anchor, the anchor event again will be fired
as if the previous anchor was freshly navigated to. The same logic
applies to navigating forward.
What this achieves:
With the anchor event handling implemented in a webpage, the page can
now react to backwards and forwards events of the browser, without
having to reload the whole page. The user can also bookmark a specific
state of the page, as specified in the URL.
Since you can already catch loads and unloads, the key part of this
proposal that seems useful is the catching of fragment identifier changes.
I've added an event (hashchanged) that fires when that happens.
On Wed, 1 Mar 2006, ROBO Design wrote:
Yet, as I see it, your suggestion is more elegant and easier to use. The
state objects defined by WA 1.0 are very good, but they might be way
too much for simple usage.
The spec has both now.
On Thu, 2 Mar 2006, Ric Hardacre wrote:
to clarify, where would the event be attached by default? document or window?
i.e. would i
function myonAnchor( e )
{
if( e.anchorName )
switch( e.anchorName )
{
...
default:
return true;
}
}
document.onAnchor = myonAnchor;
It'll be on body, the same way as onload, onunload, etc. (The exact
mechanics of that still need to be defined, actually, for all these
semi-magical body/window events.)
On Wed, 8 Mar 2006, Loune wrote:
I've had a look at the Session history and navigation state spec and
if I'm interpreting it correctly, it only solves part of the problem.
Using state objects you would:
1) Implement the popstate event
2) use the window.pushState(stateobject) to push the state into the state
stack?
3) When user navigates back, popstate event fires with the state object
From the terminology, I gather that once you popped the state, you don't
have the state in your history anymore?
This is incorrect; the state object stays in the history. You can go
backwards and forwards.
That means after you navigate back, you can't go forwards again. The
state spec also leaves room for a URI to be associated with the state.
But it begs the question of how will the URI be correlated to the state
DOMObject in way that the URI can restore the state, even if the URI is
posted to a web page, or sent via email to a friend.
That's up to the server.
I think the two specs, onanchor/state can be reconciled. The traditional
anchor jumping could be made a behaviour of a modified state spec. Each
jump will be regarded as a new state of page in the session history. It
will however need some modifications for it to be able to perform like
it is on current browsers (going forward, URL change,
Re: [whatwg] Web Applications 1.0 and Menu Labels
On Aug 7, 2007, at 9:10 AM, Ian Hickson wrote: On Mon, 22 Nov 2004, Matthew Thomas wrote: ... Given that, I approve of giving menus and submenus a disabled attribute that would make all their descendant items unavailable without forgetting the erstwhile availability of individual descendant items. This attribute would relieve applications from having to remember the particular subset of descendant items that were previously available, during those occasions when they are all temporarily being made unavailable (for example, a Format menu while focus is temporarily in a plain-text field secondary to the main rich-text area). The idea of the current mechanism, though, is that you can have those same menu items also be a toolbar elsewhere (say), so you'd want to disable the buttons anyway. Wouldn't it be better to have the menus automatically disable submenu titles when appropriate? It would be good for UAs to dim menu/submenu titles whenever all their items are disabled, if that's the platform UI convention (and perhaps even if it isn't). However, that's orthogonal to my suggestion. I'm suggesting that since it is common for entire menus -- or toolbars -- to be temporarily irrelevant, such as when focus is in a field or pane where they do not apply, there should be a disabled= attribute for disabling an entire menu. When this attribute is present, all the menu's items should be disabled, regardless of their individual disabled= attributes; when the menu's disabled= attribute is removed, the disabled= attributes of the individual items should retake effect. This would save authors a lot of work that they might otherwise not bother with, thereby making their interfaces more responsive. I do not think but the menu items might be duplicated in a toolbar is a strong counterargument. If the temporarily-irrelevant items are a subset of the items a toolbar, then yes, they will need disabling individually. But often it will be the entire toolbar that needs disabling, or the menu will not have equivalent items in a toolbar, or -- even more common in Web apps -- the toolbar will not have equivalent items in a menu. (Note that the Mac OS X guidelines seem to no longer have the quote you give above.) ... Yes, they now say the opposite! I think that's a mistake, but in any case, that doesn't affect my suggestion. It would still be useful to make an entire menu disabled even if the platform UI convention is for disabled menu titles to look enabled. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Attribute of the Location interface should not be readonly
On Sun, 17 Jun 2007, Samuel Weinig wrote: In the HTML5 spec, the attributes of the Location interface (href, host, hostname, etc.) should not be readonly as they can be set. Thanks. Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form Serialization
On 8/8/07, Garrett Smith [EMAIL PROTECTED] wrote: Most libraries now are providing a way to serialize a form. It would be useful to have: HTMLFormElement.prototype.toJSONString HTMLFormElement.prototype.getDataSetString HTMLFormElement.prototype.toJSONString would return an object literal that contains the enabled (not readonly) form element names as keys and an array for each key's value. aForm.getDataString() would return a serialized data set representation of the form's successful controls. Yes, these would be useful for 2 reasons that I can think of. 1. *Potential* ease of working around form handling bugs when you really need to. Although if the form handling is broken, the methods might be too, but it still might be easier to get the broken data set and fix it instead of generating the data set yourself. At least with getDataString, it would show you what's going to be submitted. I could imagine an onsubmit, e.preventDefault() and e.target.getDataString() being useful. 2. Form handling extensions. If you want to support the foobambang: protocol, you could use the object and its array values to generate a foobambang:-conforming URI and open it (using the default handler for foobambang URIs). -- Michael
Re: [whatwg] input usemap (was: Re: [html5] HTMLMapElement.images)
On Wed, 8 Aug 2007, Michael A. Puls II wrote: On 8/8/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Wed, 08 Aug 2007 07:54:33 +0200, Ian Hickson [EMAIL PROTECTED] wrote: 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%). The only usecase, while using input as control, seems to be to make certain parts of the image not clickable. Given that, it makes sense to me to reduce the number of attributes browsers have to implement for input... Also, besides Safari and IE not supporting input usemap, Opera's behavior of it is differs depending on whether the input is in a form or not. (If it's not in a form, it doesn't behave like a button.) Also, in Opera, if the map the input is associated with has 2 area elements, each with their own title attribute, when hovering over the coordinate range for the second area element in the image, Opera won't display a tooltip. For example, see http://shadow2531.com/opera/testcases/imagemaps/001.html Hovering over each square should show a title tooltip, but the bottom red one fails in Opera. Check in FF to compare. I've only used input usemap for test cases and can't think of any good use for it since it's not even supported well. I did a thorough study of this (details below) and I concluded that we're better off removing it. I've removed input usemap from the spec. Out of 3.5 billion or so HTML pages examined in this survey, only 0.00036% (about 12000) had a usemap= attribute on an input element pointing to a map that contained an area with both a coords= attribute and an href= attribute, the latter of which was not the empty string or a single #. These pages were distributed over about 500 separate domains. This is a sample of those pages, one per domain, strongly biased towards front pages -- if a site had an affected front page, that's the page that was selected. Any URLs with numbers, ampersands, question marks, and commas have been dropped, to make the list easier to manage. I looked at some and didn't find any pages that would be negatively affected by removing this feature. (Other people looked at some pages from an earlier study along the same lines and actually found several pages that would work _better_ if you didn't support input usemap, too.) http://alforag.com/donate/ http://antikapital.de/ http://arotrade.com/inquiry.htm http://beadsboom.com/ http://bestgt.co.kr/ http://bhc.co.jp/ http://campus.ciss.es/ciss/ http://cartucce-compatibili.it/default.asp http://cipk.cleani.info/event/event_write.php http://darrylo.com/web_promotion.htm http://directaccesscard.com/introduction.php http://dungeon.happymobile.co.kr/ http://dvs.si/ http://edodo.net/photo/ http://en.hhu.edu.cn/ http://es-marquescastilho.edu.pt/a.htm http://est.yescall.com/company/ http://exam.newstudy.net/ http://ezbizz.com/site/ http://futowncorp.com/company.html http://gateway-bayern.bib-bvb.de/ http://gctinc.com/index.html http://globulus-ural.com/links.php http://greatvision.org/ http://hammitup.com/ http://hanaroclinic.net/ http://hiddenvalleymuskoka.com/dinner.html http://hsb.ac.in/mscml.html http://intenseactionkrew.com/ http://jscorea.co.kr/audition.htm http://lifelong.kookmin.ac.kr/login.asp http://lifesupportonline.com/ http://linkcommand.com/index.php http://livevibesrecording.com/pages/purchase.html http://mail.bnet.cn/ http://mariaclaralopez.com/ http://moa-mall.com/index.php http://my.habbo.name/Flins/ http://newenglandlighting.com/newpages/new.html http://osmosys.com.mx/contacto.html http://paydayloantoday.com/ http://php.pol.fr/irce-anciens/general.html http://piperenterprisesinc.com/ http://planetabuba.net/secciones/galeria/buba/bgal.html http://pmacorp.master.com/texis/master/search/ http://promocatalog.gesupply.com/dev/help.php https://publish.insightbb.com/html-jsp/announce.htm http://realestate.bannisterdesign.com/grostick.com/search.php http://sayersautorepair.com/appt.html http://shop.divebooty.co.uk/ http://shop.divebooty.com/ http://shrewsburylumber.com/login.php http://sls.suffolk.edu/location.html http://stlcin.missouri.org/citydata/newdesign/projectmap.cfm http://store.yahoo.co.jp/samurai-japan/ http://sydneyjumpingcastles.com.au/quote.html http://taternik.pza.org.pl/ http://tbnf.e-kai.com.tw/chinese/beef_shop.php http://tessapictures.com/formB.html http://thisdancan.com/ http://tom-architekten.com/kontakt.htm http://torrebermeja.com/ http://tour.itinjeju.com/ http://towerhall.lk/ http://town.botwood.nl.ca/pages/accommodations.php http://traineverybody.com/contact.php http://tressawilliams.com/main.html http://webikorea.net/login.asp http://webmail.arnet.com.ar/ http://wemsa.com/cruise/video.htm http://weppipakki.com/html/attribs/usemap.htm http://wristbrands.co.uk/ http://www.aapkidukaan.com/ http://www.achat-vin.net/ http://www.ademi-ba.com.br/novo/main/associados/banco_curriculo.jsp
Re: [whatwg] input usemap (was: Re: [html5] HTMLMapElement.images)
On 8/9/07, Ian Hickson [EMAIL PROTECTED] wrote: I did a thorough study of this (details below) and I concluded that we're better off removing it. I've removed input usemap from the spec. Out of 3.5 billion or so HTML pages examined in this survey, only 0.00036% (about 12000) had a usemap= attribute on an input element pointing to a map that contained an area with both a coords= attribute and an href= attribute, the latter of which was not the empty string or a single #. These pages were distributed over about 500 separate domains. This is a sample of those pages ... Thanks. Much appreciated. http://www.wheresmysquare.com/ With that page from the list, it uses input type=image so that when you click on a spot in the image, the coordinates of where you clicked are submitted. usemap=#map1 is also used on the input so that when clicking on certain spots in the image (defined by the area elements), instead of submitting coordinates, a link (defined by the corresponding area element) is navigated to. Without input usemap, how would you accomplish the same? Would you just use img usemap with an area element to define the range and link for each of the ~3000 squares? If that's what you'd have to do, I suppose it doesn't matter because you have to do it anyway if you want to support more than FF and Opera. Plus, you'd have to do it anyway once the square fills up. I just thought I'd make note of that situation. Also, with input usemap, Opera (unlike FF) won't display the image context menu when you right-click. It also won't display the link context menu when you right-click on a link part of the image, so these are even more reasons to dump input usemap. I checked some of the other sites and some of them were just using input usemap instead of img usemap for now reason whatsoever. I've removed input usemap from the spec. No objections from me. -- Michael
