[whatwg] usemap= and related issues
On Wed, 15 Nov 2006, Shadow2531 wrote: beginmap/mapend In Opera and IE, you'll see beginend. In Firefox quirks mode, you'll see the same. In Firefox standards mode, you'll see: begin end The default style applied to the map element varies between browser and rendering mode. Someone once pointed out to me that even if the map element has a content model of block, that doesn't mean it should have a default style of block applied to it. That is a css issue though. Anyway, yeh, if you put stuff inside map, it takes up space except for area and param etc. I'm not sure what to do about this. I guess maybe we should just make map 'display:inline' in the default CSS? On Tue, 28 Nov 2006, Simon Pieters wrote: Currently map only allows block-level elements, and area is considered a strictly inline-level content (but only allowed as a descendant of map). HTML4 allowed either block-level elements or areas as children of map, where the idea with block-level elements was to use a paragraph or a list with a elements that acted as areas. When authors switch from HTML4 to HTML5 they will find that the conformance checker complains about lack of block-level elements in map and then they will just insert a div or a p around all areas and complain about the change. Now a can't act as areas anymore in HTML5. But why are block-level elements required? Is the intent that authors should place their areas in paragraphs or lists? Why? Isn't it better to only allow areas as children of maps, and then let UAs treat the areas as being a list of links when used as fallback (as described in [1])? [1] http://www.hixie.ch/specs/html/usemap-alt This is moot now right? On Wed, 8 Aug 2007, Anne van Kesteren 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... Ok it's only on img and object. On Wed, 8 Aug 2007, Michael A. Puls II wrote: Just wan to be sure: Even though id is required, name is allowed on map. Correct? (It currently needs to be for Safari and Firefox in text/html or image maps won't work (even on trunk versions) I've changed the spec to require name= instead of requiring id=, based on the collective feedback on this issue. 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'm trying to minimise the differences, so I've left it as insensitive. On Fri, 10 Aug 2007, Benjamin Hawkes-Lewis wrote: Since HTML5 handles standard HTML, tag soup, and faux-XHTML (i.e. almost all public web content), what is the benefit of introducing a backwards incompatibility with the XHTML 1.x specifications for the application/xhtml+xml serialization, in which any content (the esoteric cases Hixie mentioned) correctly relying on case sensitivity would break? The only time this would break anything is if a page is using XML _and_ relying on two names different only in case to match differently. That's a pretty specific case and unless someone knows of a case that does this, I'm willing to risk breaking it to get the simplicity of fewer differences between the modes. On Sat, 18 Aug 2007, Jonas Sicking wrote: Since ID is case sensitive everywhere else, I don't see a reason to make an exception from that rule here. That seems to unnecessarily complicate implementation as well as introduce weird inconsistencies for authors. It already is inconsistent for usemap=. At least for legacy Web content I don't think we can do much about it. At that point, I'd rather just extend that to XHTML than to keep another difference. On Mon, 20 Aug 2007, Jonas Sicking wrote: Why can't you keep ids case sensitive always for all those? Seems weird from a user perspective that ids are case sensitive in all cases except this one. Well, they should be using name= anyway, so it's not like they'll run into this much. In gecko we keep a hash for id-element which is case sensitive. This hash is used for the implementation of getElementById, anchor scrolling, and anything else that uses ids. We also have a hash for name-element which is case insensitive, this hash is used for things like form.elements.foo and document.foo and anything else that uses names. What you suggest is to add a third hash for id-element which would be case insensitive and only used for maps. I think a hash would be overkill for this, except for the rare
Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
Ian Hickson wrote: On Mon, 8 Oct 2007, Brad Fults wrote: 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document? I'm wondering if he was thinking about cases where the element is shorter vertically than the viewport? It might be worth clarifying what happens in that case. I assume the answer is nothing? Secondly, with respect to this section as a whole, I see no description of necessary behavior for horizontal scrolling. Surely this is an issue that must be addressed, as it would be decidedly deficient if scrollIntoView() only took vertical scrolling into account, leaving horizontally overflown content still outside of the viewport after the method's invocation. Do UAs do any horizontal scrolling today? I've mentioned it, but I'm not sure what to say really. Well, it seems like you could offer instructions analagous to the vertical case, substituting left and right for top and bottom, no? That could imply a second argument to the function... Matt -- Matt Bonner Hewlett-Packard Company -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, June 03, 2008 4:33 AM To: Brad Fults Cc: WHAT-WG Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view On Mon, 8 Oct 2007, Brad Fults wrote: There are a couple of problems I have found in this section. If it isn't possible to show the entire element in that way, or if the argument is omitted or is true, then the user agent must instead simply align the top of the element with the top of the viewport. [1] I have two issues with this text: 1. The word simply is rhetoric and doesn't seem reasonable or useful in the context of this part of the specification. Removed. 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document? Secondly, with respect to this section as a whole, I see no description of necessary behavior for horizontal scrolling. Surely this is an issue that must be addressed, as it would be decidedly deficient if scrollIntoView() only took vertical scrolling into account, leaving horizontally overflown content still outside of the viewport after the method's invocation. Do UAs do any horizontal scrolling today? I've mentioned it, but I'm not sure what to say really. -- Ian Hickson U+1047E )\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] several messages
On Sun, 17 Jul 2005, Dean Edwards wrote: Anne van Kesteren wrote: Shouldn't the print method on the window DOM interface be defined as well? Example: button onclick=window.print()print/button IE has some nice onbeforeprint/onafterprint events. Can we add these too? Defined both. On Mon, 18 Jul 2005, Olav Junker Kjær wrote: Arent these event mostly used to transform the view before printing it? I think this is better handled by a print-specific style-sheet today. There are some things for which CSS just doesn't work, sadly. On Tue, 19 Jul 2005, Greg Kilwein wrote: DG wrote: a) my invoice format requires a timestamp that says something like this: printed by [person] on [timestamp]. b) To capture the essence of the browsing session, I would like to build a breadcrumb at the bottom of the printed page, displaying titles and urls of pages the user have visited on the site during this visit. This is now possible. I'll add another case: the onafterprint event could be used in a wizard-style application where printing some document is step 3 of 10, for example. The application could proceed to the next step (not necessarily a different document) automatically without requiring a button that says click here when done printing. That's a case that a media-specific stylesheet cannot handle. Automating tasks and reducing clicks are both high priorities in my development of web applications. Good use case! If the ability to set printer settings such as portrait/landscape is available, an onbeforeprint event could be used to prompt the user whether they'd like to automatically switch their paper orientation to portrait or landscape before printing. (The same can be said for margins and headers/footers.) This can be done in the print dialog, but if it is truly important to how the page prints, a separate step that highlights the importance of the print setting to the user would be helpful in reducing calls to my company's tech support line. As specified, you could indeed use showModalDialog() for this. [snip other use cases] On Wed, 20 Jul 2005, Matthew Raymond wrote: Once again, I don't understand why you can't simply provide the user with a button on the web page that either calls up a printable version or clones the document so that the clone can be used for printing. (Granted, there probably isn't support for the latter, but it makes more sense to standardize that than to add onbeforeprint and onafterprint, especially when you consider the fact that a clone of the document can be held in memory for repeated printing or dumped.) I don't see why we shouldn't have both; after all, people are using onbeforeprint today, and it doesn't seem to have caused a disaster or anything. As far as I can tell, no part of WF2 or WA1 encourages malicious behavior on the part of the webmaster against the users. In fact, part of the problem I had with dataentry was that it could, in theory, be use in a hostile way towards legacy user agents. Therefore, I doubt this will ever make it into a WHATWG spec, especially when it can interfere with simple things like printing selected text, et cetera. This hasn't happened much, but certainly a user agent could disable scripts while it is printing. Now you've completely lost me, use-case-wise. On an intranet, why is a printable version of the document not an acceptable workaround? Well it's not as nice, is it. I mean, it's not the same experience really. Look at printing in Google Maps, for instance, where it brings up another page -- it's not as seamless as just printing the current page. Here's a question for you to chew on: What happens if you want to print and the webmaster screwed up something in the onbeforeprint or onafterprint event? Will it effectively disable printing? Will the document be restored once printing is finished? What if it's an AJAX application and the UI of the app is hidden for printing but never restored? This can all happen without printing too. On Wed, 20 Jul 2005, Matthew Raymond wrote: I think there's good enough reason to disallow a feature when you have the following: 1) The feature can be abused. 2) It alters the standard behavior of the browser. 3) It can be easily disabled with a modified open source browser or browser extension. ...or the browser can just allow it to be overriden. Point 3 basically counteracts the first two, imho. 4) Its use cases are partially covered by CSS. CSS is just as susceptible to 1 and 2, why isn't that a problem? 5) There are existing workarounds. Workarounds are just that. Not solutions. 6) An alternative has been proposed that has less potential for abuse, is more powerful, and doesn't change basic browser functionality. I don't see how it has less potential for abuse, really. I also am not sure it's really more powerful. On Wed, 20 Jul
Re: [whatwg] access to local path in input type=file
On Thu, 20 Mar 2008 20:58:03 -0300, ddailey [EMAIL PROTECTED] wrote: In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user to change the src attribute of an image based on her perusal of local file space. Opera 9.5 doesn't seem to allow access to the path data necessary for accomplishing this rollover effect, and I suspect that may be how it is supposed to be according to emerging standards. ... Hi David, you might be interested in the fileIO proposal [1] from Opera in the WebAPI group at W3C, which is designed to allow for this kind of use case. [1] http://dev.w3.org/2006/webapi/fileio/fileIO.htm cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
