[whatwg] Proposal for an addition to the authoring guidance regarding the alt attribute

Section 4.8.1.1.9 describes how alternative text for content images should be written: http://www.w3.org/TR/html5/embedded-content-1.html#a-key-part-of-the-content Then, there is a general guideline about writing alternative texts in section 4.8.1.1.12: "A corollary to this is that the alt att

Re: [whatwg] Please consider simplifying authoring guidance for the alt attribute

Am 02.08.2010 20:54 schrieb Ashley Sheridan: On Mon, 2010-08-02 at 17:19 +0200, Markus Ernst wrote: - search engines should generally ignore text in the alt attribute, but evaluate the title attribute instead Rationale: 4.8.1.1.12 says: "A corollary to this is that the alt attribute&#x

Re: [whatwg] Please consider simplifying authoring guidance for the alt attribute

Am 01.08.2010 11:43 schrieb Tantek Çelik: http://wiki.whatwg.org/wiki/Img_Alt I encourage fellow web authors to add opinions/comments. My personal opinion on the alt attribute is that: - it should only be used if the image is crucial for understanding the content, or for navigation (such as h

Re: [whatwg] "Content-Disposition" property for tags

Am 02.08.2010 18:21 schrieb Michael Kozakewich: Dennis wrote: Yes, but that wouldn't help since I want to force downloads regardless of the browser settings. Maybe it would do if the type was set to application/octet-stream, since those, by default, always get downloaded. People don't often li

[whatwg] Cross-origin opt-in for seamless iframes [was: Iframe dimensions]

Am 06.07.2010 12:31 schrieb Aryeh Gregor: On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst wrote: Thank you and Boris for your examples. I see the security issues. Anyway It would be very helpful in cases like mine, where security and privacy are not affected, to get an easy way to do this opt-in

Re: [whatwg] Iframe dimensions

Am 06.07.2010 22:41 schrieb Ashley Sheridan: On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote: On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst mailto:derer...@gmx.ch>> wrote: > My problem is this sentence in the spec for seamless: "This will cause links > to open in th

Re: [whatwg] Iframe dimensions

Am 06.07.2010 12:31 schrieb Aryeh Gregor: On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst wrote: Thank you and Boris for your examples. I see the security issues. Anyway It would be very helpful in cases like mine, where security and privacy are not affected, to get an easy way to do this opt-in

Re: [whatwg] Iframe dimensions

Am 05.07.2010 22:50 schrieb Aryeh Gregor: On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst wrote: Some content from an external specialized content provider is included in an existing web site via an iframe. This cannot be seamless, as the links in the iframe must point to the original domain of

Re: [whatwg] Iframe dimensions

Am 05.07.2010 19:24 schrieb Adam Barth: On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst wrote: First, this sounds somehow complicated to me, and second, I don't understand why the dimensions of non-seamless iframes should not get the benefits of author-friendly (and user-friendly) dime

[whatwg] Iframe dimensions

Hello I found that the dimensions of the iframe element are handled along with those of other embedded content such as img, video and others: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width There is no indication about what a UA should do when dime

Re: [whatwg] select element should have a required attribute

Am 19.06.2010 21:07 schrieb Garrett Smith: What is the correct expectation for the outcome of submitting a SELECT that has a disabled, selected OPTION? I can't answer this exact question, but to go back to the original question: Maybe this is the point where the @required attribute makes sens

Re: [whatwg] Image resize API proposal

Am 11.05.2010 20:58 schrieb Sterling Swigart: I'm working with David Levin, and based on the feedback received regarding offscreen canvas, the proposal has been changed to address more specific scenarios. The main use case was resizing images, so we are proposing an asynchronous image resizing

Re: [whatwg] Type Date

Am 07.05.2010 00:30 schrieb Schalk Neethling: Just to rectify any misunderstanding, I love the date picker that Opera provides and others will hopefully do in turn but, my question is that currently using type=date only provides the option of selecting a date using the date picker. In a recent

[whatwg] Keywords for the pattern attribute [was: RFC: ]

Am 06.05.2010 15:18 schrieb Smylers: Schalk Neethling writes: if your username field will be in the form of an email address, then simply use type=username with a pattern to facilitate email validation. Surely a major reason for having standard validation types is so web developers don't need

Re: [whatwg] RFC:

Am 05.05.2010 23:06 schrieb Schalk Neethling: The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both develope

Re: [whatwg] Two propositions for the autofocus attribute

Am 25.04.2010 22:08 schrieb Eitan Adler: - multiple autofocused elements per page are valid, but only one per form Is it possible to focus on multiple elements at the same time even in different forms? If they are both text boxes and a user types which element gets the keyboard input? Autofocus

Re: [whatwg] Two propositions for the autofocus attribute

Am 16.04.2010 09:30 schrieb Kit Grose: On 16/04/2010, at 5:06 PM, Markus Ernst wrote: Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting. What if the form is received via XHR as HTML and

Re: [whatwg] Two propositions for the autofocus attribute

Am 16.04.2010 02:44 schrieb Kit Grose: On 16/04/2010, at 9:08 AM, Jonas Sicking wrote: While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this.

Re: [whatwg] Changing punctuation value of input element in telephone state

Am 07.04.2010 01:28 schrieb Eduard Pascual: Maybe I'm being too hasty with this idea but, since machines don't really need the same readability aids as humans do, I'd suggest that the UA simply removes everything other than "+" and alphanumeric characters (and obviously adds nothing) when sending

Re: [whatwg] borders on images inside links

Ashley Sheridan schrieb: On Tue, 2010-03-02 at 01:56 -0800, Maciej Stachowiak wrote: On Mar 2, 2010, at 1:41 AM, Maciej Stachowiak wrote: > 2) I do not believe the proposed rule is a good default for either > documents or applications. It looks ugly. I randomly checked 10 of > the sites I b

[whatwg] External link and new window policy [was: @sandbox and navigation top]

Maciej Stachowiak schrieb: On Feb 12, 2010, at 11:54 PM, Adam Barth wrote: On Fri, Feb 12, 2010 at 11:48 PM, Michal Zalewski wrote: Can a frame in @sandbox ever navigation the top-level frame? If not, that would make it hard to use @sandbox to contain advertisements, which want to navigate

Re: [whatwg] Lists and legal documents

Tab Atkins Jr. schrieb: On Sat, Feb 6, 2010 at 4:31 AM, Markus Ernst wrote: o ... o ... Simply putting the checkbox as the first content in the works well for me there. You can then suppress the list-style or not. No, as multiline label text will render as: o ... . A (I think

Re: [whatwg] Lists and legal documents

Anne van Kesteren schrieb: Legal documents often use various indicators for list items. E.g. a. ... b. ... c. ... or 1. ... 2. ... 3. ... or I. ... II. ... III. ... or A. ... B. ... C. ... etc. These indicators are part of the content and cannot be governed by

Re: [whatwg] window.print() when printing is not supported

Robert O'Callahan schrieb: On Tue, Dec 29, 2009 at 6:07 AM, Boris Zbarsky > wrote: Come to think of it, airline boarding passes are the only case in which I print things from the web using either print buttons or the browser's "print" functionality. Are ther

Re: [whatwg] window.print() when printing is not supported

Michael A. Puls II schrieb: On Mon, 28 Dec 2009 14:39:06 -0500, Michael A. Puls II wrote: On Mon, 28 Dec 2009 12:08:48 -0500, Boris Zbarsky wrote: On 12/28/09 9:54 AM, Michael A. Puls II wrote: As for window.print(), what if it returns false if printing is not supported? It might be be

Re: [whatwg] window.print() when printing is not supported

Anne van Kesteren schrieb: On Mon, 28 Dec 2009 12:54:00 +0100, Olli Pettay wrote: currently http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#printing says that window.print() should prompt user to print the page, but that "For instance, a kiosk browser could silently ig

Re: [whatwg] Uploading directories of files

Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole poi

Re: [whatwg] Uploading directories of files

Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst wrote: Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded

Re: [whatwg] Uploading directories of files

Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept

Re: [whatwg] Uploading directories of files

Ian Fette (イアンフェッティ) schrieb: I would think it preferable if .name also were allowed to contain that extra information -- currently we say "The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information." [1]. I

Re: [whatwg] boolean attributes in javascript

Tab Atkins Jr. schrieb: On Tue, Dec 8, 2009 at 3:48 PM, Brian Kuhn wrote: but it's invalid to set it to anything other than the two values I just mentioned. That's the part I'd like to see changed. I understand that if it's present, it's on. So, why can't async="true" be valid? I think al

Re: [whatwg] [HTML5] A content in elements for ASCII art

David Bruant schrieb: Tab Atkins Jr. a écrit : It's impossible at this point to make elements take contents. They're void elements in every single browser in existence. => I take this argument as a "pro" argument for two reasons : - are void elements in every single browser, so, if this "s

[whatwg] Custom attributes [was: Adding a src attribute to all elements]

Michael A. Puls II schrieb: On Wed, 04 Nov 2009 05:03:49 -0500, Markus Ernst wrote: Tab Atkins Jr. schrieb: On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II wrote: On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala wrote: For instance, if I create a level 1 header that looks like: This

Re: [whatwg] Adding a src attribute to all elements

Tab Atkins Jr. schrieb: On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II wrote: On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala wrote: For instance, if I create a level 1 header that looks like: This is a header The text "This is a header" would be replaced with the image that's located

Re: [whatwg] WebStandrd for theme

narendra sisodiya schrieb: On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov wrote: narendra sisodiya schrieb: Many blogging site like posterous has theme editor for their blog/website. It is a xml file looks more like html. Following file was a long file which I have edited and deleted the unnece

Re: [whatwg] HTMLElement.onload

Ian Hickson schrieb: On Sun, 25 Oct 2009, Markus Ernst wrote: The spec says in 3.2.3: "The following event handler content attributes may be specified on any HTML element" - with my quite trivial understanding, I would actually expect something to happen if I do this. The note "

Re: [whatwg] HTMLElement.onload

Simon Pieters schrieb: On Fri, 23 Oct 2009 17:16:13 +0300, Markus Ernst wrote: In 6.5.6.2 of the spec I found, that the onload event handler is now available for every HTML element in HTML5, which I think is a great improvement. But there is something on the load event, that I think would

[whatwg] HTMLElement.onload

In 6.5.6.2 of the spec I found, that the onload event handler is now available for every HTML element in HTML5, which I think is a great improvement. But there is something on the load event, that I think would be worth some words to clarify. According to 6.11.2 the load event is fired when th

Re: [whatwg]

Daniel Glazman schrieb: > Hi there, > > That onlyreplace attribute is not enough, and trust me, I have > spent quite a while on solutions transforming HTML documents using > bits contained in external instances... > > Hixie referenced at some point in the thread my HTMLOverlays proposal > [1] and

Re: [whatwg]

Aryeh Gregor schrieb: On Mon, Oct 19, 2009 at 4:49 AM, Markus Ernst wrote: - If none of the indicated IDs are found, *replace the whole page*. This makes it possible to prevent e.g. a wiki or forum from being @onlyreplaced by just using different IDs. But it breaks progressive rendering

Re: [whatwg]

Tab Atkins Jr. schrieb: On Mon, Oct 19, 2009 at 3:49 AM, Markus Ernst wrote: What do you think about: 1. Defining which ids are to be replaced: - The list of IDs to replace is in tag, as described earlier in this thread. and elements can have a boolean @onlyreplace attribute that

Re: [whatwg]

Tab Atkins Jr. schrieb: On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor wrote: Some attention needs to be given to error handling. What happens if one or more of the requested id's aren't found? Do they silently fail? If so, this could result in the link doing absolutely nothing in hard-to-c

Re: [whatwg]

Tab Atkins Jr. schrieb: On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking wrote: Also, what should happen if the user presses the 'back' button? If the browser can remember what the page state was previously, just swap in the old parts. If not, but it at least remembers what parts were replace

Re: [whatwg]

Tab Atkins Jr. schrieb: [...] The body of page1.html could look like: Recipies for vegetarians Lovely broccoli Take the broccoli and do the following: ... Broccoli Leak The body of page2.html: Recipies for meat eaters Lovely leak Take the leak and do the following: ... Broccol

Re: [whatwg]

Tab Atkins Jr. schrieb: Promoting this reply to top-level because I think it's crazy good. [...] Let's say we add a new attribute to , like , where "foo" is the id of an element on the page. Or better, a space-separated list of elements. When the user clicks such a link, the browser should do

Re: [whatwg] No interface flicker across page loads, without JavaScript (was: framesets)

Aryeh Gregor schrieb: On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes wrote: As an aside, there is a reason why AJAX has become so popular over the past few years: it solves the specific UI-reset issue that is inherent in full-page refreshes. I'm trying to think what a solution to this would

Re: [whatwg] window.setInterval if visible.

Gregg Tavares schrieb: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to

Re: [whatwg] framesets

Aryeh Gregor schrieb: On Wed, Oct 14, 2009 at 11:56 AM, Peter Brawley wrote: Correct, but excluding frameset from HTML5 increases the likelihood that browsers will drop support for the feature. The spec requires all browsers to support framesets. Look: http://www.w3.org/TR/html5/obsolete.ht

[whatwg] disabled and readonly attributes

In 4.10.15.2 (disabled) and 4.10.5.2.3 (readonly) I can't find out what UAs should submit if an element is disabled resp. readonly: - nothing - the default value - any value that might have been entered, or assigned via DOM, before disabled resp. readonly was set to true - any value that might h

Re: [whatwg] The legend element

Ian Hickson schrieb: [...] I would recommend not using and for rows 2 and 3. As in: Placeholder outputs of 2nd row: {label}: What is favourite pet? {input-html}: Cat Dog Ant Placeholder outputs of 3rd row: {label}: When are you born? {input-html}: Mo

Re: [whatwg] framesets

tali garsiel schrieb: Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I guess it's not a HTML5 question but more a "best practice" question but ... In case an application has navigation menus that cannot be reloaded each time.Only the conten

Re: [whatwg] The legend element

Ian Hickson schrieb: On Mon, 12 Oct 2009, Markus Ernst wrote: Ian Hickson schrieb: Additionnally I want to suggest to make it possible to place the legend element outside the fieldset element, providing a "for" attribute (just as it is possible to place the label element apart from

Re: [whatwg] The legend element

Ian Hickson schrieb: Additionnally I want to suggest to make it possible to place the legend element outside the fieldset element, providing a "for" attribute (just as it is possible to place the label element apart from it's form field element). This is significantly harder to pull off, fo

Re: [whatwg] framesets

Peter Brawley schrieb: >So, if the people who discuss and define the HTML5 standard *do not like* framesets, >it is IMO reason enough for them to take them out of this standard. Thwere we disagree. A main W3C responsibility is to facilitate the web. Removing a feature /which is used because

Re: [whatwg] framesets

Peter Brawley schrieb: Eduard, >Everything that can be achieved with can be done through >+. If that's so, someone ought to be able to point at some examples. I think that the discussion if or not there may be a use case where framesets are "good" is not the point. Supposing that someone

[whatwg] The legend element

I found this post by Ian Hickson from August 15, 2006 in the list archive: > On Sat, 1 Apr 2006, Henri Sivonen wrote: > > > > Since the omission of does not cause any horrible effects, > > I suggest making optional and reaffirming that if it > > appears, it can appear only once per and only as

Re: [whatwg] HTML 5 Script Tag

Tab Atkins Jr. schrieb: On Thu, Aug 6, 2009 at 6:14 PM, Cready, James wrote: You make a great point. But whether or not you use the XML/XHTML or the HTML 4 doesn¹t matter much. Since like I showed in my previous example: the instant you specify a src attribute on your opening tag the browser

Re: [whatwg] do not encourage use of small element for legal text

Ian Hickson schrieb: On Thu, 4 Jun 2009, Andrew W. Hagen wrote: Encouraging use of small print for legalese also encourages this: Welcome to the BigCo web site. Click to continue. By clicking above, you agree that BigCo can charge your credit card $10 per visit to the BigCo web site per pa

Re: [whatwg] HTML as a text format: Should be optional?

Øistein E. Andersen schrieb: On 18 Apr 2009, at 00:02, Randy Drielinger wrote: If you're converting from a textfile, title could refer to the filename. It could, but chances are that the original filename would typically be less useful than the URL, which is what most browsers use when the

Re: [whatwg] optgroup element used for selection

Markus Ernst schrieb: Randy Drielinger schrieb: Currently (HTML4.01) and in the near-future HTML5 spec optgroup elements are used to group options (hence the name :-) and amongst others allow us to disable a group of option elements at once. Personally, I think it would make sense to add the

[whatwg] Nested optgroups

I found a message in the list archives from July 2004, where Ian announced to put nested optgroups back into the spec: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/001200.html Anyway in the current spec, the optgroup element is not allowed inside another optgroup element: http

Re: [whatwg] optgroup element used for selection

Randy Drielinger schrieb: Currently (HTML4.01) and in the near-future HTML5 spec optgroup elements are used to group options (hence the name :-) and amongst others allow us to disable a group of option elements at once. Personally, I think it would make sense to add the ability to make an opt

Re: [whatwg] Input type for phone numbers

Boris Zbarsky schrieb: Antti Koivisto wrote: I'd like to propose a new type attribute value for phone numbers ( perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A use

Re: [whatwg] Hyphenation

Ian Hickson schrieb: On Tue, 9 Jan 2007, �istein E. Andersen wrote: Hyphenation does not seem to have been discussed on this list so far, and I think it should be. Old proposal: [2] http://www.nada.kth.se/i18n/html/hyph.html While I appreciate the problems faced by Swedish, German, and o

Re: [whatwg] List Headers

Benjamin Hawkes-Lewis schrieb: On 4/2/09 20:39, Garrett Smith wrote: Dry: 1c flour 1/4c sugar 1tsp baking soda Wet: 1 egg 1/2c milk 1tsp vanilla extract Hmm. Does that markup solve any user problems that following traditional, markup does no

Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]

Eduard Pascual schrieb am 29.10.2008 18:37: On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst <[EMAIL PROTECTED]> wrote: Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: "Ok, great work... but this loo

Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]

Ian Hickson schrieb: [...] Why is that a problem? Is converting one to the other a common occurance? I'm not really convinced it's that much work. Assuming that the radio buttons and/or checkboxes are written in a consistent manner, which they usually are, a simple regexp search-and-replace on

Re: [whatwg] Solving the login/logout problem in HTML

Ian Hickson schrieb: ...and there must be a element with name="login", which represents the form that must be submitted to log in. Forgive me if this is a stupid question... but anyway: Are there other cases where values of the name attribute have special functionalities? Otherwise, I'd sugg

Re: [whatwg] SPOOFED: Re: ---

Pentasis schrieb: This I understand, and I can even sympathise with it. However, I do hope that at least "they" will take this issue seriously and at least try to build in something that will enable "us" to work on that part of the spec independantly later on. I still think that the semantic pa

Re: [whatwg] ---

Pentasis schrieb: The HTML5 spec is open to feedback from linguists, typographers and content creators. I would agree we should particularly give consideration to people with those backgrounds with regards to issues of semantics. On the other hand, there is not total freedom here because

[whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]

Ian Hickson schrieb: On Tue, 28 Oct 2008, Markus Ernst wrote: [...] I consider a total re-thinking of select, input type="checkbox" and input type="radio" elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than f

Re: [whatwg] Form Control Group Labels

Ian Hickson schrieb: On Tue, 31 Oct 2006, Lachlan Hunt wrote: There are workarounds using fieldset and legend for the question, like this. Gender: Male Female That's not a workaround. It's exactly what you're supposed to do. lets you group a set of controls with a common

Re: [whatwg] Proposal for a link attribute to replace

- provided UAs interpret attributes of unknown tags, they will even be capable to correctly handle occurrences of when the A element will be totally removed from their code. -- Markus Ernst

[whatwg] Form control consistency

t element I assume that this is possible without breaking backwards compatibility. At least, new browsers will be able to interpret HTML4 syntax. Old browsers will not be able to interpret all of my suggestions, but AFAICS this is the case also with other new parts of HTML5. -- Markus Ernst

<    1   2