Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: Jun 2, 2008 5:39 AM On Mon, 02 Jun 2008 05:26:40 +0200, Ernest Cline [EMAIL PROTECTED] wrote: The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. Sure, but anchor is not backwards compatible with specs or user agents. That might be a reason to adjust the spec for a to have it match current behavior, but in my opinion it would be better to provide for the block/inline distinction to be handled with recourse to CSS by having separate elements as is the case for div/span. There are alternatives to obtain this behavior in old browsers without using a in a block context, so the loss of backward compatibility would be a minor issue at most. That said, adjusting the spec to have a follow current behavior would be better than leaving the spec as it is and not have any spec compliant method to provide a block level hyperlink without the use of scripting.
Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 31, 2008 5:02 AM To: Ernest Cline [EMAIL PROTECTED], WhatWG [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline [EMAIL PROTECTED] wrote: What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well. The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite a, h3, and p appearing in all of them. a href=foo.html h3Heading/h3 pText/p /a The specs have always called for a to only have inline content save that for some reason, HTML 2.0 did allow h1 to h6 inside a though that was not recommended, and that was reverted back to inline only in 3.2. While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.)
Re: [whatwg] Proposal for a link attribute to replace a href
Having looked at the discussion thus has generated, I have a counterproposal to make. First of all, given that full support for hyperlinks requires support for seven attributes (href, target, ping, rel, media, hreflang, type), I can fully understand web developers not wanting to make it something applicable to any element. On the other hand, web authors have already indicated a desire through how they use a with exist tag soup browsers to have hyperlink support for more than just phrasing content as supported by a and embedded content as supported by area for img and object. What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well.
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Mike Wilson [EMAIL PROTECTED] Sent: May 15, 2008 8:02 AM To: 'WHATWG' [EMAIL PROTECTED] Subject: Re: [whatwg] Thoughts on HTML 5 - dialog Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson Because of the backwards compatibility using dt and dd with a new dialog element would have with most existing UA's, I'd be leery of changing the names unless additional types of child elements for dialog/ (by whatever name it gets) were added, such as an element to markup stage directions, audience response, or the like. Then, since we'd be introducing enough new stuff to break compatibility anyway: dialog/ speaker/ (what dt/ currently is) speech/ (what dd/ currently is) fx/ (a new element for stage effects, audience response etc.)
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 6:09 PM To: Paweł Stradomski [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Thoughts on HTML 5 On Tue, 13 May 2008, Paweł Stradomski wrote: W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). The only synonym of dialog that is anywhere near as general seems to be discourse/. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling.
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 8:08 PM Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. Is there any reasonable chance an element for a dialog box might end up being added to XForms? (There is a proposal mentioned on the XForms wiki [1] for a possible dialog element for XForms 2.0, but I have no idea how much of a chance that proposal has as opposed to extending the message element.) I know that XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem for those that will be using various flavors of XHTML with XForms is worth addressing now. If XForms were to add an explicit dialog box element, what name other than dialog/ would be appropriate? [1] http://www.w3.org/MarkUp/Forms/wiki/Dialogs
[whatwg] link rel=icon sizes=? What if sizes is incorrect?
On further reflection, I'll concede that the style attribute is probably better suited to deciding what to do with the icon once it is fetched. Using it as metadata to decide what is fetched is problematic if multiple sizes are to be allowed to be specified in a single link element. However I do see some problems with the proposed sizes attribute. Mainly, I am troubled by the statement: The keywords specified on the sizes attribute must not represent icon sizes that are not actually available in the linked resource. No matter what the spec says, I think we can all agree that once this enters the real world there will be times when the icon size given is wrong. So what to do? At a minimum, I think the behavior called for when dealing with the type attribute is called for: User agents must not consider the type attribute authoritative — upon fetching the resource, user agents must not use metadata included in the link to the resource to determine its type. However once a mismatch is discovered, does that mean that the icon that has been retrieved should be scaled as if it were an img, or should the icon be discarded and the next icon which matches the available parameters be used instead?
Re: [whatwg] link rel=icon width=
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 5, 2008 5:27 AM On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] wrote: Perhaps, but it means adding attributes to link elements that will only be needed for a single link type. If the use case for these attributes is strong enough to add special purpose attributes for use with only link rel=icon then I dare say that it is strong enough to have a special purpose icon element so as to keep user agents from having to deal with nonsense such as link rel=stylesheet height=32 width=32 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. Would making icon an optional content of title break backwards compatibility? The incompatibility problem you mention comes from the start and end tags of both head and body being optional. That isn't the case for title and it makes sense syntactically to place it there as the icon is part of the identifying information for the document.
Re: [whatwg] link rel=icon width=
-Original Message- From: Aaron Boodman [EMAIL PROTECTED] Sent: May 3, 2008 2:33 PM On Sat, May 3, 2008 at 8:13 AM, fantasai [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: By contrast, I do not know of any actual need to determine the aspect ratio of an SVG icon or the duration of a sound icon. I do not know of cases where HI guidelines for particular platforms would recommend different choices of icon aspect ratio or sound icon duration. Thus, I suggest we limit ourselves to adding only the info that is actually known to be needed at this time. If UI innovation creates a need for more info, we can add it to the spec then. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. Why? To me it seems much preferable to separate the attributes of an object into separate name/value pairs then trying to mash them all together into one value. Perhaps, but it means adding attributes to link elements that will only be needed for a single link type. If the use case for these attributes is strong enough to add special purpose attributes for use with only link rel=icon then I dare say that it is strong enough to have a special purpose icon element so as to keep user agents from having to deal with nonsense such as link rel=stylesheet height=32 width=32
Re: [whatwg] link rel=icon width=
-Original Message- From: Smylers [EMAIL PROTECTED] Sent: May 1, 2008 3:02 AM Ernest Cline writes: ... proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size Maybe I'm missing something obvious, but why wouldn't: link rel=icon style=width: 16px; height:16px serve to mark width and height adequately? * The style attribute says _how_ to display something, not what that something _is_. The above says: Ignore the icon's intrinsic size and scale it to 16 x 16. Unless width and height attributes for link are going to behave differently than they do on other elements, that's the behavior they'd have anyway. (See section 3.12.17 Dimension attributes) If new attributes are added to the link element to represent the intrinsic size of an object, then at the very least they should have different names and not confuse things by assigning two separate meanings to height and width based on the element they are attached to. * CSS is optional, so browsers shouldn't be forced to use it to find out some meta-data. And if a user had elected to turn off CSS for displaying in pages, would a browser still be permitted to use it for this purpose? The whole use of link rel=icon is a stylistic concern in the first place. Limiting the optimal use of rel=icon to instances in which CSS is used does not strike me as an excessive burden. * Nested attribute syntax is more awkward and error-prone than having width and height directly on the element. Maybe slightly, but is it enough of an advantage to outweigh the added browser overhead needed to add support for two attributes to every instance of link even tho it is useful to only one particular linktype, particularly since support for the alternative I offered needs to be available in the first place. It's even perfectly fine HTML 4 syntax. Why is that interesting? If it's syntax that current browsers already do something useful with then that's a big point in its favour; but if it's something which is currently a no-op then that it happens to be syntactically permitted in an older standard doesn't seem like a benefit over any other syntax which browsers currently ignore. I can't say if any current browsers currently make use of it, but it is syntax they need to be able to handle in some manner. One strong argument for using the style attribute instead of adding new attributes is that it does not increase the amount of overhead a browser is expected to handle.
Re: [whatwg] link rel=icon width=
-Original Message- From: Maciej Stachowiak [EMAIL PROTECTED] Sent: May 1, 2008 9:34 PM To: Maciej Stachowiak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Ian Hickson [EMAIL PROTECTED] Subject: Re: [whatwg] link rel=icon width= height= On Apr 29, 2008, at 10:13 PM, Maciej Stachowiak wrote: I would suggest a sizes attribute which can take a list of sizes (with x as a width/height separator), or a keyword such as any or scalable to indicate a scalable format suitable for any size. link rel=icon type=application/svg sizes=any href=whatwg.svg link rel=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link rel=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link rel=icon type=image/png sizes=59x60 href=whatwg.png OK, I'm sure the last thing that is needed is more syntax suggestions, but here's an alternate proposal with no new attributes, specify size info as additional rel keywords: link rel=icon scalable type=application/svg href=whatwg.svg link rel=icon 16x16 32x32 type=image/microsoft.vnd.icon href=whatwg.ico link rel=icon 16x16 32x32 64x64 128x128 256x256 512x512 type=image/ x-apple-icons href=whatwg.icns link rel=icon 59x60 type=image/png href=whatwg.png This would however effectively define an open-ended set of rel values, and also it is dubious whether a size can be considered a relationship. Regards, Maciej If this approach is taken, rather than preempt any possible use of size related values for icons, how about: link rel=icon type=application/svg href=whatwg.svg link rel=icon icon-16 icon-32 type=image/microsoft.vnd.icon href=whatwg.ico link rel=icon icon-16 icon-32 icon-64 icon-128 icon-256 icon-512 type=image/x-apple-icons href=whatwg.icns link rel=icon icon-59x60 type=image/png href=whatwg.png Using icon-* to indicate square icons and icon-*-* to indicate non-square icons would give a specific relationship of it being an icon a specific size for a particular rel value and not be quite so open ended. Scalability is already indicated by the type attribute and could be left to be implied by the use of just plain icon without any of the more specific markers. The use of the plain icon keyword on the ones with specific sizes indicated would only be needed for backward compatability with UAs that don't understand the extended forms proposed here.
Re: [whatwg] link rel=icon width=
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: Apr 29, 2008 9:52 PM To: [EMAIL PROTECTED] Subject: [whatwg] link rel=icon width= height= (With my rarely-used Google hat on:) The Gears team has an API that allows authors to specify a set of icons: http://code.google.com/apis/gears/upcoming/api_desktop.html They used a scripted API, but when I tried to get them to use a declarative API, they said that the main reason they used a scripted one is that the declarative options didn't have a way to specify dimensions. This is a proposal to add height and width attributes to link specifically for the case of rel=icon, so that authors can provide multiple icons and let the UA decide which to use based on their size (without having to download them all to find out which is best). Opinions? Maybe I'm missing something obvious, but why wouldn't: link rel=icon style=width: 16px; height:16px serve to mark width and height adequately? It's even perfectly fine HTML 4 syntax. Ernest Cline
[whatwg] Error: 2nd example datetime for the time element
In section 3.10.10, the second example is: time datetime=2006-09-24 05:00 -7 However, the algorithm given in 3.2.4.2 for parsing date or time strings requires that the timezone hour offset be exactly 2 digits. (This is the same requirement ISO 8601 has.) Hence, the example as given is invalid according to the provided parser algorithm, since it has only 1 digit. Ernest Cline
Re: [whatwg] Expanding datetime
-Original Message- From: Henri Sivonen [EMAIL PROTECTED] The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. Native date widgets already need to deal with BCE dates at the DOM level as they are well within the range of a DOMTimeStamp. In ECMAScript the range of years for which any time in the year can be represented is from 283,459 BCE to 287,398 AD. What is being proposed is allowing a document to specify such times in the document without having to resort to scripting by expanding the range of values the datetime attribute can represent. The draft is already proposing making changes to the existing HTML 4 specification of datetime by allowing only the date or the time to be given instead of the full date and time, so datetime is already being proposed to be changed, so the question therefore is not should we change datetime, but rather what other changes would be worth incorporating so as to avoid having to change datetime a second time. (For instance, since DOMTimeStamp uses a millisecond granularity, allowing datetime to specify milliseconds may be of use as well.)
Re: [whatwg] Expanding datetime
-Original Message- From: WeBMartians [EMAIL PROTECTED] Can the standard state that datetime strings support ISO 8601:2004 and leave it at that? (just a thought) Considering the considerable number of formats that ISO 8601:2004 encompasses, I don't think that would be a good idea. The following format possibilities for specifying instants in time, while acceptable to ISO 8601:2004 would not be worth adding to HTML 5 under any use case I can imagine. I really can't see why they bothered with the century format except as supplemental field for pre Y2J applications that used a 2 digit year field. Decimal minutes and hours are allowed in ISO 8601:2004, but lead to problems with rounding once one gets to increments smaller than 0.0001 min and 0.1 h respectively, so should probably not be adopted. The alternate ways of representing 1985-04-12: the ordinal date (1985-102) and the week date (1985-W15-5) don't offer anything that would justify the extra complexity that would be required of the parser. In case the specification ever develops a use case for a comma separated list of datetime values, then the use of comma as an alternate to the period for the decimal point should not be allowed. HTML 4 currently allows only: -##-##T##:##:##Z -##-##T##:##:##+##:## -##-##T##:##:##-##:## These three formats are a subset of those suggested by the W3C datetime note [1] which itself is a subset of the choices available under ISO 8601. The HTML 5 draft currently extends this to allow: * leaving out the seconds (valid under the W3C datetime note) * adding a decimal point and one or more digits for fractional seconds (valid under the W3C datetime note) * specifying just the date (valid under the W3C datetime note) * specifying just the time (valid under ISO 8601, but not the W3C datetime note) * replacing the T separator between the time and date with whitespace (NOT VALID under ISO 8601) * including some optional whitespace in some specific places (NOT VALID under ISO 8601) Unless allowing the whitespace is needed to back standardize an existing implementation's handling of ins/del, it should be removed from the draft as it is not ISO 8601 compliant and complicates the job of the parser, though I grant it does improve the human readability slightly. As a side issue, unless attribute values are restricted to ISO/IEC 656 characters, ISO 8601 appears to call for also accepting U+2010 HYPHEN as a separator between the fields of a date value, and U+2212 MINUS for the sign in a time zone designator or extended year representation. The following is a list of steps for a parser that accepts a wide range of valid ISO 8601 datetime formats, assuming that extended years are of the format ±Y and that at most 3 digits are allowed after the FULL STOP in the seconds. Variables date, time, and zone are booleans for whether a date, time, or timezone was present in the designation. Variables year, month, day, hour, minute, second, millisecond, zonehour, and zoneminute contain the correct results, but range checking for nonsense values as 2007-02-29 or even 2007-13-42 is not done, nor is converting them to value stored in the DOM. 0. Set month and day to 1; set hour, minute, second, and millisecond to 0; set date, time, and timezone to invalid; advance to the first non-whitespace character. 1. If the next character is not PLUS, MINUS, or HYPHEN-MINUS, skip to step 5. 2. If the next character is not PLUS, set year to -1, else set year to 1. 3. Advance 1 character; if the next five characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 4. Set date to valid; multiply year by the value given by the next five characters; advance 5 characters; skip to step 7. 5. If the next four characters are not in the set DIGIT ZERO .. DIGIT NINE, skip to step 17. 6. Set date to valid; set year to the value given by the next four characters; advance 4 characters. 7. If the next character is whitespace, COMMA, or end of string, end as valid. 8. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid. 9. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 10. Set month to the value given by the next two characters; advance 2 characters. 11. If the next character is whitespace, COMMA, or end of string, end as valid. 12. If the next character is not HYPHEN or HYPHEN-MINUS, abort as invalid. 13. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 14. Set day to the value given by the next two characters; advance 2 characters. 15. If the next character is whitespace, COMMA, or end of string, end as valid. 16. If the next character is not LATIN CAPITAL LETTER T abort as invalid. 17. If the next two characters are not in the set DIGIT ZERO .. DIGIT NINE, abort as invalid. 18. Set time to valid; set hour to the value given by the next two characters; advance 2 characters.
Re: [whatwg] Expanding datetime
-Original Message- From: Lachlan Hunt [EMAIL PROTECTED] Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? So the web is now used only for business? And we'll be able to predict exactly what uses users will want to make of it? I think not. The original reason for limiting years to a four digit format was that the relevant standard allowed only that. That is no longer the case. At minimum, with signed years now available as an optional part of ISO 8601, datetime should support ±-MM-DD dates, so as to cover historical dates which some users may find of use, though admittedly probably not business users. Adding one or two additional digits would also enable a closer match with the range of time values allowed in the DOM representation, and would need to be added at the same time as the ± is added.
[whatwg] Expanding datetime
The range of valid datetime strings is a subset of those specified by ISO 8601. Most of the unused formats have been rejected on the grounds of simplicity of parsing, but a format (I think added in ISO 8601:2004, but it may have been earlier) offers a gain in utility that would not be unduly complicated to implement. Datetime is current limited to years in the range of - . Additional digits could be added to the year and still keep the string a valid ISO 8601 string, provided that the number to be added is agreed to and the added digits are always preceded by either a + or -. For example, if one digit is added, then the day before -01-01 could be represented as -1-12-31. From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. The Y10K problem can also be pushed back by this, but is of only theoretical impo rtance. That said, a decision would be need to be made as to the number of extra digits. ISO 8601 requires an implementation to specify a fixed number of added digits, because otherwise a value such as +00019 would be ambiguous in a implementation that used the full set of ISO 8601 formats. (+00019 could be the year 19 AD or the 19th century AD, depending upon whether one or three digits was added.) That datetime doesn't use lone centuries doesn't matter. Since the DOM assumes that time values will be stored as per ECMAScript type floats, for me the question of how many digits to add boils down to a simple one. Is it preferable for all dates specified by datetime strings to be valid values to store in a Date object in ECMAScript, or would it be better for all values in a Date object to have a valid datetime string? Currently the specification for datetime, because of its limit to four digits years goes along with the former not the latter. We could add one digit and increase the range of allowable years from 100,001 BC to 99,999 AD and stay with in the range of a Date object. Adding two digits, would allow all Date objects to have a representation as a datetime string. (Adding zero digits and just adding the ability to add a sign is also an option, but would in my opinion be lesser than either of the other two options.)
