[whatwg] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the elements HTMLCollection an array
(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.
(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named watch. It is a bad practice and I see this influence in the
popular libraries.
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call push et c directly on that NodeList object (see the
dojo.NodeList for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.
// WRONG
document.forms[0].qty,
The elements property is what the example should use:-
// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get
This avoids ambiguity when having a form that has an element named name,
for example. It becomes ambiguous as to whether the form.name refers to
the element or the form's name attribute. Problems could also arise with
action, length, toString, elements.
-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
} else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
}
}
And further down:-
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;
if (myControl.value == '[EMAIL PROTECTED]') {
myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:
var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;
if (qv.valueMissing) {
// Value required but not filled in.
} else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
}
}
var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
addr.setCustomValidity(addErrInvalidMsg);
}
[whatwg] Fake Code
Examples should work.
Citation from:
http://www.whatwg.org/specs/web-apps/current-work/#outlines
The following JavaScript function shows how the tree walk could be
implemented. The root argument is the root of the tree to walk, and
the enter and exit arguments are callbacks that are called with the
nodes as they are entered and exited. [ECMA262]
function (root, enter, exit) {
var node = root;
start: do while (node) {
enter(node);
if (node.firstChild) {
node = node.firstChild;
continue start;
}
while (node) {
exit(node);
if (node.nextSibling) {
node = node.nextSibling;
continue start;
}
if (node == root)
node = null;
else
node = node.parentNode;
}
}
}
This code cannot be interpreted in a compliant implementation of
EcmaScript. It has more syntax errors than I can count. It is unclear
what the author thinks this code will do. If its intent were clearer,
and the syntax errors fewer, it might be possible for me to help out
by fixing them. The above code is not even close to ECMA262.
Examples should not contain errors.
Garrett
Re: [whatwg] image element
On 30 Jul 2008, at 4:49 am, Ian Hickson wrote: On Tue, 20 Mar 2007, Nicholas Shanks wrote: I asked for the resurrection of HTML+'s imagefallback/image element last month. The reasons I cited were exactly the same as the reasons being given now in favour of the video element, however I was told (paraphrasing) Why bother, you can just use object and That would break existing implementations (though no such implementations were cited). To continue this: The video and audio elements are being introduced because they have DOM APIs that exceed that of object, and we don't want to overload the general element with features specific to certain kinds of media. By analogy, images could have specific APIs too (dontScale/scaleToFit/ stretchToFit, nextFrame/previousFrame/startAnimating/stopAnimating). These aren't being proposed at present, but overloading object is not something it seems like we should be telling people to do. I would expect, if an analysis was done, that the number of people using image/ as an empty element (thinking they were using img), and the number of people using image/image as was defined in HTML+ are both no higher than the background noise of misspelled tags. As such, I don't believe it would be to any vendor's detriment to change the meaning of an opening image tag to not be empty, since the numbers of pages rendered incorrectly would stay about the same (just that it would be a different set of pages). The action, however, would free up the tag for future use. So again, I ask for an image element to replace img. Benefits include: - As video would cater for video/* MIME types, image would cater for image/* I don't see how this is a benefit over img. In order of importance to me: 1. It's spelt correctly. 2. It's not an empty element. 3. It's spelt correctly. - The alt and longdesc attributes can be part of the fallback content, allowing markup. If you need markup in the fallback, use object. (Or, better, consider exposing the content to everyone and not making it only available to those who don't see the image.) The point of fallback is ‘help for people who can't see the image’ rather than ‘an explanation of the image suitable for all’. Of course, if you can provide the latter, that's great, and there's no problem. Fallback content could be as simple as Figure 2, where the surrounding text discusses the image sufficiently that it isn't necessary to see the image, but users still want to know which image element on the page that text was referring to (so they can download it to disk, or whatever). - You don't have to provide a type attribute and match on: object [type^=image/] Seems like img handles this too. Aye, but img gets me very angry. I believe this was the worst moment in the history of HTML: http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html Why did nobody stop this guy at the time? We're still cleaning up his mess 15 years later :-( — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Fake Code
And this particular example should be recursive. Unfolding inherently
recursive procedures with an explicit stack, perhaps to construct an
enumerator or to simulate a coroutine, is a technical detail that does not
belong here.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:46 AM
To: WHATWG List
Subject: [whatwg] Fake Code
Examples should work.
Citation from:
http://www.whatwg.org/specs/web-apps/current-work/#outlines
The following JavaScript function shows how the tree walk could be
implemented. The root argument is the root of the tree to walk, and
the enter and exit arguments are callbacks that are called with the
nodes as they are entered and exited. [ECMA262]
function (root, enter, exit) {
var node = root;
start: do while (node) {
enter(node);
if (node.firstChild) {
node = node.firstChild;
continue start;
}
while (node) {
exit(node);
if (node.nextSibling) {
node = node.nextSibling;
continue start;
}
if (node == root)
node = null;
else
node = node.parentNode;
}
}
}
This code cannot be interpreted in a compliant implementation of
EcmaScript. It has more syntax errors than I can count. It is unclear
what the author thinks this code will do. If its intent were clearer,
and the syntax errors fewer, it might be possible for me to help out
by fixing them. The above code is not even close to ECMA262.
Examples should not contain errors.
Garrett
Re: [whatwg] image element
He was the vendor of the prototype implementation so it was impossible to stop him although TBL did his best. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Shanks Sent: Wednesday, July 30, 2008 9:17 AM To: Ian Hickson Cc: WHAT Working Group Mailing List Subject: Re: [whatwg] image element Aye, but img gets me very angry. I believe this was the worst moment in the history of HTML: http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html Why did nobody stop this guy at the time? We're still cleaning up his mess 15 years later :-( - Nicholas Shanks.
Re: [whatwg] HTML 5 : Misconceptions Documented
Form attribute names should take precedence over form control names. There
is no ambiguity. Both mechanisms belong to Netscape DOM and are deprecated.
Form property names should take precedence over both. I do not see much
value in removing support for legacy code altogether; it looks a bit
totalitarian to me. I agree, however, that examples provided should use
modern wording, whatever that means.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the elements HTMLCollection an array
(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.
(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named watch. It is a bad practice and I see this influence in the
popular libraries.
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call push et c directly on that NodeList object (see the
dojo.NodeList for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.
// WRONG
document.forms[0].qty,
The elements property is what the example should use:-
// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get
This avoids ambiguity when having a form that has an element named name,
for example. It becomes ambiguous as to whether the form.name refers to
the element or the form's name attribute. Problems could also arise with
action, length, toString, elements.
-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
} else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
}
}
And further down:-
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;
if (myControl.value == '[EMAIL PROTECTED]') {
myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:
var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;
if (qv.valueMissing) {
// Value required but not filled in.
} else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
}
}
var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
addr.setCustomValidity(addErrInvalidMsg);
}
Re: [whatwg] Application deployment
The documents belonging to the container should not be available directly from the server, except when they are served via a server extension that goes to the container to get them. This effect should be easy to achieve on the server side. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: Wednesday, July 30, 2008 6:45 AM To: Dave Singer Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Application deployment On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer [EMAIL PROTECTED] wrote: Caching is on a full URL basis, of course. Once that is decided, then yes, I think that pre-cached items for a given URL are in the general cache for that site. A site that uses this feature is likely to be fragile. It will have to have z.html both in the archive and available directly from the server, in case z.html is requested before the load of the archive has finished. And if those copies ever get out of sync you're in very big trouble, because depending on the context, either the archive version or the direct version is likely to consistently win the load race, so just occasionally some clients will get the wrong version. This seems like a highly error-prone design. Rob
Re: [whatwg] Application deployment
On Tue, Jul 29, 2008 at 5:10 PM, Russell Leggett [EMAIL PROTECTED]wrote: That is a performance killer. I don't think it is as much of a performance killer as you say it is. Correct me if I'm wrong, but the standard connection limit is two. The standard connection limit is 6, not 2, as of IE 8 and Fx 3. I would be very surprised if this came back down or was not adopted by all other browser makers over the next year or two. Furthermore, the connection limit applies only to resources off one host. Sites have for years gotten around this by sharding across hosts ( img1.foo.com, img2.foo.com, ...). There are many reasons resources can cause slowdown on the web, but I don't view this archive proposal as useful in solving them compared to existing tactics. Server sharding and higher connection limits solve the problem of artificially low connection limits. JS script references block further parsing in most browsers; the correct solution to this, as Ian said, seems like some variant of Safari's optimistic parser. Referencing large numbers of tiny images causes excessive image header bytes + TCP connection overhead that can be reduced or eliminated with CSS spriting. The only thing archives get you IMO is difficulty with caching algorithms, annoyances rewriting URLs, potentially blocked parsing, and possibly inefficient use of network bandwidth due to reduced parallelization. Archives remove the flexibility of a network stack to optimize parallelization levels for the user's current connection type (not that I think today's browsers actually do such a thing, at least not well; but it is an area with potential gains). PK
Re: [whatwg] img element comments
The element you are describing is effectively a progress bar control. It is still not present in HTML; however, it can be emulated using an OUTPUT control with layout or with invisible text and a custom background: SPAN STYLE=COLOR: RED; BACKGROUND: RED; BORDER: THIN SOLID BLACK ***/SPAN Alternatively, if you scorn at the number of asterisks, you can use INPUT TYPE=TEXT SIZE=13 DISABLED. This has the disadvantage of being irrelevant to screen readers. HTH, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 5:08 AM To: Matthew Paul Thomas Cc: WHATWG Subject: Re: [whatwg] img element comments On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: I don't think If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file. solves any real problem given what browsers already have to implement, so I'd remove that sentence. As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. https://translations.launchpad.net/ubuntu We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using canvas, so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. As far as I'm aware, the behaviour you describe for w3m matches what all the UAs do. I'm not sure that this usage of img is one that the spec today considers valid. Wouldn't canvas be the better way to do this?
Re: [whatwg] Fake Code
On Tue, 29 Jul 2008, Garrett Smith wrote:
Citation from:
http://www.whatwg.org/specs/web-apps/current-work/#outlines
The following JavaScript function shows how the tree walk could be
implemented. [...]
This code cannot be interpreted in a compliant implementation of
EcmaScript. It has more syntax errors than I can count. It is unclear
what the author thinks this code will do. If its intent were clearer,
and the syntax errors fewer, it might be possible for me to help out by
fixing them. The above code is not even close to ECMA262.
Fixed. As far as I can tell, the only problem was an extraneous do. I
tested the code after removing the odd extra do and it worked fine.
Tested by calling the function test and evaluating the following:
var s = ;
test(document,
function (a) { s += enter + a + \n; },
function (a) { s += exit + a + \n; });
s
The output was what I expected. There were no syntax errors. Could you
elaborate on what else you think is wrong other than the do?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fake Code
On Wed, 30 Jul 2008, Kristof Zelechovski wrote: And this particular example should be recursive. Unfolding inherently recursive procedures with an explicit stack, perhaps to construct an enumerator or to simulate a coroutine, is a technical detail that does not belong here. The point of the exercise is to show that it is possible to implement this easily without recursion. The example was added in response to implementor feedback requesting it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] image element
On Wed, 30 Jul 2008, Nicholas Shanks wrote: To continue this: The video and audio elements are being introduced because they have DOM APIs that exceed that of object, and we don't want to overload the general element with features specific to certain kinds of media. By analogy, images could have specific APIs too (dontScale/scaleToFit/stretchToFit, nextFrame/previousFrame/startAnimating/stopAnimating). These aren't being proposed at present, but overloading object is not something it seems like we should be telling people to do. We have img for this already. I would expect, if an analysis was done, that the number of people using image/ as an empty element (thinking they were using img), and the number of people using image/image as was defined in HTML+ are both no higher than the background noise of misspelled tags. 0.2%. More common than abbr, q, dfn, kbd, ins, var, del, samp, etc... I don't see how this is a benefit over img. In order of importance to me: 1. It's spelt correctly. 2. It's not an empty element. 3. It's spelt correctly. 1 and 3 are non-issues, sorry. 2 is already handled by object when you need it. If you need markup in the fallback, use object. (Or, better, consider exposing the content to everyone and not making it only available to those who don't see the image.) The point of fallback is �help for people who can't see the image� rather than �an explanation of the image suitable for all�. Of course, if you can provide the latter, that's great, and there's no problem. Fallback content could be as simple as Figure 2, where the surrounding text discusses the image sufficiently that it isn't necessary to see the image, but users still want to know which image element on the page that text was referring to (so they can download it to disk, or whatever). My point is that the alternative text (the fallback) will often be useful for everyone, not just those who can't see the image. But that if you really don't want people to see both, you can use object anyway. Aye, but img gets me very angry. With all due respect, this may be more a problem for you than for the language. :-) The spelling of the tag is not a real problem. The lack of rich fallback isn't a problem at all, since we have object. I don't really see any issue here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Expanding datetime
On Wed, 23 Apr 2008, Ernest Cline wrote: 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 importance. Dates outside the near past and near future really aren't in any of the use cases for date types in HTML5 so far. For far away dates, use cases almost always end up being far more complicated, requiring things like range support, vague date support (e.g. just the month and year, or just the year, or a range of days in a month and year), explicit calendar support, etc. So supporting those dates really isn't a problem that we need to solve, at least as far as addressing the use cases put forth so far. Note that supporting old dates gets especially dicey given that calendars changed to the Gregorian calendar at different dates in different countries, so you have to include geographic information as well to convert old dates into Gregorian-equivalent dates. This is really an area of complexity that we do not want to specify in HTML5. On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. On Fri, 25 Apr 2008, Christoph P�per wrote: What about, for instance, adjustable timelines at history websites or virtual skies at astronomic sites? Neither of these would likely use type=date. Timelines probably would rather use logarithmic year selectors (e.g. using type=range), and virtual skies for dates far away will typically use Julian dates (which are more like type=number step=any). On Thu, 24 Apr 2008, Charles wrote: Genealogy would seem to be another relatively popular use. Genealogy's use of dates is far, far more complex and involved for old dates than anything type=date can do. On Fri, 25 Apr 2008, Henri Sivonen wrote: I think the questions are: * Are there use cases for entering proleptic Gregorian dates before the Common Era in a Web form (input type=date)? * Are there use cases for representing proleptic Gregorian dates before the Common Era in a way that moving the data to a calendar app (time)? * Are there use cases for annotating document modifications with proleptic Gregorian dates before the Common Era (ins/del)? I think the answer to the ins/del case is no. The future is intended for tracking changes in computer documents, and all historical documents have been migrated to computer documents in the Common Era. I think the answer to the calendar at case is in no. The calendar app case is about planning future events. You don't need time markup when writing about historic events before the Common Era--in particular, if you write about events that are referred to by their Julian dates. As for the form case, it seems implausible to me that sites about the history of urban planning or ecology would require users to enter dates that are more precise than to the year. In the case of sites about historic events, it also seems implausible that users would be competent to enter precise proleptic Gregorian dates for searching events that occurred when the Julian Calendar was in use (or in other locales a calendar that *looks* different, too). To make calculations with the precision of a year, the user interface could use a form field that takes a number and sidestep the issue of converting the year two seconds or milliseconds. The historic astronomy case seems awfully narrow to justify making native date widgets deal with BCE dates. I agree with all these points. On Thu, 24 Apr 2008, Lachlan Hunt wrote: 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
Re: [whatwg] Proposal for a link attribute to replace a href
Every now and then, the issue of a global href= attribute for all
elements comes up. There are many valid use cases for this, like being
able to make all cells in a table row act like a link, or making a banner
ad act like a single block of a link.
Unfortunately, I've been told over and over by implementers that a global
href= is a bad idea, and at the end of the day, the implementors are the
ones who have the final say, so that's just a non-starter.
There are also alternative suggestions, like making a contain any
element. Unfortunately, none of these end up working (e.g. for this
proposal, ap/a would create an unexpected DOM -- we'd have to make
/p end tags not optional when the next end tag was an /a, which would
be somewhat confusing).
So I apologise again for rejecting these proposals, and hope that it
doesn't discourage you from contributing further to other aspects of
HTML5.
I haven't included all the feedback on this topic that I received, but
here is a sampling with some responses:
On Wed, 28 May 2008, Martin Atkins wrote:
I agree that this is an unconvincing example, but consider instead
banner ads that are created from a bunch of HTML markup rather than a
single image; they generally want the entire banner rectangle to be
clickable but make use of tables and all sorts of other strange
things.
Just do:
div class=ad onclick=this.getElementsByTagName('a')[0].click()
...a href=...Buy viagra!/a...
/div
(Note that .click() is new in HTML5.)
On Thu, 29 May 2008, Frank Hellenkamp wrote:
But I step over different kinds of teaser (news- and article-teasers)
during my work, that are made out of images, text and headlines.
Now, you have to do this (without javascript):
div class=teaser
a href=link.htmlimg src=image.png/a
h3a href=link.htmlnewsteaser/a/h3
pa href=link.htmlText/a/p
pa href=link.htmlText/a/p
/div
If you are good, you also set the a-elements to display: block so that
the whole area is clickable, not only the text.
It would be *much* more simple/useful to have something like this:
div class=teaser href=link.html
img src=image.png
h3newsteaser/h3
pText/p
pText/p
/div
Or this:
a href=link.html
div class=teaser
img src=image.png
h3newsteaser/h3
pText/p
pText/p
/div
/a
You could just do:
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
h3a href=link.htmlNews Teaser/a/h3
figure
img src=image.png alt=...
legend.../legend
/figure
pText/p
pText/p
/article
...or some such (article and figure are new in HTML5).
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
On Sat, 31 May 2008, Shannon wrote:
http://www.duttondirect.com/automotive/for_sale
The table hover effect is not easily acheived without global href. My
client likes it, the users like it and it is perfectly obvious
navigation (despite being non-standard). At the moment I am acheiving
the effect with event bubbling but I consider this approach to be
bloated, ineligant, prone to breakage and lag on slower devices. It also
suffers from the poor compatibility of the event.button property
(activates on right/middle-click instead of just left). Nonetheless it
improves the ease of navigation for most users.
A global href would allow me too turn the whole mess of event code into:
tr href=foo.html ... /tr
... and all the issues I just mentioned would vanish.
Sure. What's wrong with doing this, though?:
tr onclick=location = this.querySelector(:link,:visited).../tr
(querySelector() is new in the Selectors API spec.)
Is global href a burden on browser vendors?
Unlikely. It's behaviour is nearly identical to onclick=window.location=foo
which is already supported on the majority of modern browsers except Lynx.
We don't get to decide if it's a burden or not, they do.
On Fri, 30 May 2008, Ernest Cline 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.
We already have three elements that do linking in HTML5, adding a fourth
seems like a lot.
On Sat, 31 May 2008, Anne van Kesteren wrote:
The a element can already do this and it would be backwards
compatible.
As far as I can tell this breaks down for ap.../a.
On Sun, 1
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008 13:50:18 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. -- Simon Pieters Opera Software
Re: [whatwg] Proposal for a link attribute to replace a href
Simon Pieters wrote: On Wed, 30 Jul 2008 13:50:18 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. There are also alternative suggestions, like making a contain any element. Unfortunately, none of these end up working (e.g. for this proposal, ap/a would create an unexpected DOM -- we'd have to make /p end tags not optional when the next end tag was an /a, which would be somewhat confusing). The rules for optional end tags are already pretty confusing. I don't think it's a problem to require /p when the p element is the last child of an a element. I think tableatr also causes problems; being able to link whole table rows seems like one of the major use cases for this proposal. Would the implementor feedback that global href is a bad idea still apply if instead of global it was large set of elements where the large set would explicitly not include things like form elements? -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008 15:29:47 +0200, James Graham [EMAIL PROTECTED] wrote: I think tableatr also causes problems; Indeed. being able to link whole table rows seems like one of the major use cases for this proposal. I don't know how to do that short of using script. Perhaps HTMLElement should have a links collection to make it simpler to write the script? tr onclick=links[0].click() Would the implementor feedback that global href is a bad idea still apply if instead of global it was large set of elements where the large set would explicitly not include things like form elements? Allowing href in more places is potentially a security problem since suddenly you could run scripts from things that blacklist-based sanitizers don't filter out. -- Simon Pieters Opera Software
Re: [whatwg] Application deployment
The only thing archives get you IMO is difficulty with caching algorithms, annoyances rewriting URLs, potentially blocked parsing, and possibly inefficient use of network bandwidth due to reduced parallelization. I don't see any reason that parsing would need to be blocked any more than it already is. No rewriting of URLs would be necessary at all, and I have already provided suggestions for simple solutions that would prevent unnecessary blocking. Server sharding and higher connection limits solve the problem of artificially low connection limits. JS script references block further parsing in most browsers; the correct solution to this, as Ian said, seems like some variant of Safari's optimistic parser. Referencing large numbers of tiny images causes excessive image header bytes + TCP connection overhead that can be reduced or eliminated with CSS spriting. Server sharding and CSS sprites are both artificial solutions that are used to deal with limitations of the existing deployment model. If you are worried about fragility, look no further than css sprites. They have to be background images, and require precise measurement of size and location. This creates extremely tight coupling between the css code and the file itself. Not to mention the maintenance of the sprite images themselves. Clearly we are already dealing with the problems of resource loading and how to make it most efficient. Our existing solutions are widely varied and complex, but all of them result in changes to our html/css/js code that would not already be there if we did not have that limitation. It seems to me that many of the additions to the HTML spec are there because they provide a standard way to do something we are already doing with a hack or more complicated means. CSS sprites are clearly a hack. Concatenating js files are clearly a hack. Serving from multiple sub-domains to beat the connection limit is also a workaround. My proposal is intended to approach the deployment issue directly, because I think it is a limitation in the html spec itself and therefore, I think the html spec should provide its own solution. My proposal may not be the best way, but assuming the issue will be dealt with eventually by some other party through some other means does not seem right either. -Russ On Wed, Jul 30, 2008 at 4:27 AM, Peter Kasting [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 5:10 PM, Russell Leggett [EMAIL PROTECTED] wrote: That is a performance killer. I don't think it is as much of a performance killer as you say it is. Correct me if I'm wrong, but the standard connection limit is two. The standard connection limit is 6, not 2, as of IE 8 and Fx 3. I would be very surprised if this came back down or was not adopted by all other browser makers over the next year or two. Furthermore, the connection limit applies only to resources off one host. Sites have for years gotten around this by sharding across hosts ( img1.foo.com, img2.foo.com, ...). There are many reasons resources can cause slowdown on the web, but I don't view this archive proposal as useful in solving them compared to existing tactics. Server sharding and higher connection limits solve the problem of artificially low connection limits. JS script references block further parsing in most browsers; the correct solution to this, as Ian said, seems like some variant of Safari's optimistic parser. Referencing large numbers of tiny images causes excessive image header bytes + TCP connection overhead that can be reduced or eliminated with CSS spriting. The only thing archives get you IMO is difficulty with caching algorithms, annoyances rewriting URLs, potentially blocked parsing, and possibly inefficient use of network bandwidth due to reduced parallelization. Archives remove the flexibility of a network stack to optimize parallelization levels for the user's current connection type (not that I think today's browsers actually do such a thing, at least not well; but it is an area with potential gains). PK
Re: [whatwg] img element comments
Kristof Zelechovski writes: The element you are describing is effectively a progress bar control. It is still not present in HTML HTML 5 introduces progress for that: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level.html#the-progress Smylers
Re: [whatwg] image element
Nicholas Shanks writes: On 30 Jul 2008, at 4:49 am, Ian Hickson wrote: I don't see how this is a benefit over img. In order of importance to me: 1. It's spelt correctly. 3. It's spelt correctly. Having both img and image elements in HTML doing different things would be confusing. Many people currently pronounce img as image, so it would be very hard to distinguish between these elements when talking about images. Smylers
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson writes:
... global href= attribute for all elements ... Unfortunately, I've
been told over and over by implementers that a global href= is a bad
idea
Noted.
However:
div class=ad
onclick=this.getElementsByTagName('a')[0].click()
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
It may be, given implementers' requirements, that JavaScript solutions
like the above are the best we can do. But let's not pretend they are
as good as links that don't involve scripting.
Smylers
Re: [whatwg] image element
On 30 Jul 2008, at 08:17, Nicholas Shanks wrote: So again, I ask for an image element to replace img. Benefits include: - As video would cater for video/* MIME types, image would cater for image/* I don't see how this is a benefit over img. In order of importance to me: 1. It's spelt correctly. 2. It's not an empty element. 3. It's spelt correctly. Re: 2) — it is, and it has to be for backwards compatibility (it is changed to an img element in the tokenizer, though). In terms of 1 and 3, how about starting with something that is completely wrong, not just an abbreviation, such as the Referer header in HTTP? Not that that can actually be changed, because things rely upon it… -- Geoffrey Sneddon http://gsnedders.com/
Re: [whatwg] HTML 5 : Misconceptions Documented
On Wed, Jul 30, 2008 at 1:00 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Form attribute names should take precedence over form control names. There
is no ambiguity.
Both mechanisms belong to Netscape DOM and are deprecated.
Form property names should take precedence over both. I do not see much
value in removing support for legacy code altogether; it looks a bit
totalitarian to me.
Removing support? Did you try to say that I was asking for an
implementation change, and that you thought that such change was
totalitarian. Your reaction to whatever I wrote seems quite a bit
off.
I agree,
With what?
however, that examples provided should use
modern wording, whatever that means.
Apparently, even you don't know what you mean.
The examples in any standards doc should not use Implementation
Specific Extensions, even if such code appears to work in 4 browsers.
Garrett
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the elements HTMLCollection an array
(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.
(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named watch. It is a bad practice and I see this influence in the
popular libraries.
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call push et c directly on that NodeList object (see the
dojo.NodeList for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.
// WRONG
document.forms[0].qty,
The elements property is what the example should use:-
// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get
This avoids ambiguity when having a form that has an element named name,
for example. It becomes ambiguous as to whether the form.name refers to
the element or the form's name attribute. Problems could also arise with
action, length, toString, elements.
-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
} else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
}
}
And further down:-
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;
if (myControl.value == '[EMAIL PROTECTED]') {
myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:
var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;
if (qv.valueMissing) {
// Value required but not filled in.
} else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
}
}
var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
addr.setCustomValidity(addErrInvalidMsg);
}
Re: [whatwg] Proposal for a link attribute to replace a href
What about an alternative attribute like navigate instead of href. It
would not carry the full weight of the anchor tag, but would handle the 90%
use case. It would not allow for the same options as the a tag, and the a
tag would continue to work the same way that it has been.
On Wed, Jul 30, 2008 at 10:45 AM, Smylers [EMAIL PROTECTED] wrote:
Ian Hickson writes:
... global href= attribute for all elements ... Unfortunately, I've
been told over and over by implementers that a global href= is a bad
idea
Noted.
However:
div class=ad
onclick=this.getElementsByTagName('a')[0].click()
article class=teaser
onclick=location = this.getElementsByTagName('a')[0]
On Thu, 29 May 2008, Frank Hellenkamp wrote:
In the best case the whole rectangle of the teaser is clickable. At the
moment you need some javascript or an a-tag with display: block for
it, to get this behavior (see example in my last mail).
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
It may be, given implementers' requirements, that JavaScript solutions
like the above are the best we can do. But let's not pretend they are
as good as links that don't involve scripting.
Smylers
Re: [whatwg] Application deployment
At 21:45 -0700 29/07/08, Robert O'Callahan wrote: On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Caching is on a full URL basis, of course. Once that is decided, then yes, I think that pre-cached items for a given URL are in the general cache for that site. A site that uses this feature is likely to be fragile. It will have to have z.html both in the archive and available directly from the server, in case z.html is requested before the load of the archive has finished. No. The definition *for MPEG-21 files* (which is all I have specified so far) is that accesses to the matching absolute URL (or relative URL) from within the archibe MUST find the resource within the archive. Since, as I say, this format starts with a directory, you know whether you have it or not. If ZIP or JAR files don't have a directory, then yes, they have a different trade-off and must load the whole thing before they know. You only need a resource *outside* the archive if it is requested 'nakedly' from outside the archive. If you do that, it might indeed hurt, but that's your choice as a site. The performance trade-off is very simple; if you have many small resources it may be much more efficient to ftch them as a package than individually. The downside is that this is a single connection in a pre-defined order whereas multiple resources could be fetched on parallel connections, and as needed. I doubt more connections to the same server gets you more bandwidth, however, and the mpeg-21 format also allows extent-based interleaving so that e.g. a lareg HTML page and and large JPEG can be loaded progressively together. And if those copies ever get out of sync you're in very big trouble, because depending on the context, either the archive version or the direct version is likely to consistently win the load race, so just occasionally some clients will get the wrong version. This seems like a highly error-prone design. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- David Singer Apple/QuickTime
Re: [whatwg] Application deployment
Please explain why you consider concatenating JavaScript sources dirty. You can have a library of all JavaScript definitions relevant to your site in one source file and I am not sure what is wrong with it, except that a library should consist of books, but that concept was already broken long ago. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russell Leggett Sent: Wednesday, July 30, 2008 4:25 PM To: Peter Kasting Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Application deployment It seems to me that many of the additions to the HTML spec are there because they provide a standard way to do something we are already doing with a hack or more complicated means. CSS sprites are clearly a hack. Concatenating js files are clearly a hack. Serving from multiple sub-domains to beat the connection limit is also a workaround. My proposal is intended to approach the deployment issue directly, because I think it is a limitation in the html spec itself and therefore, I think the html spec should provide its own solution. My proposal may not be the best way, but assuming the issue will be dealt with eventually by some other party through some other means does not seem right either.
Re: [whatwg] Proposal for a link attribute to replace a href
By the current spec, the Anchor element is phrasing content, which is a special case of flow content. Did you mean transparent content instead? EC! I cannot see any inline content in HTML5, at least not in 3.4.1 where content models are defined. Chris -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 1:50 PM Cc: WhatWG Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sun, 1 Jun 2008, Ernest Cline wrote: 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.) Changing the specs to match user agent behavior is the whole way HTML5 works, so that's not a big problem. The problem is that the current parse model results in odd behaviour if we allow a as a flow-content element.
Re: [whatwg] Expanding datetime
I feel uneasy about this Gregorian bias in dates, although I use Gregorian calendar myself. It seems Gregorian dates do not require specifying the datetime attribute but all other dates do (like Arabic lunar, Jewish, Thai, Ethiopic, whatever). It would be much better if the algorithm were locale-dependent, although this would probably require having HEAD META[NAME=LOCALE]. I understand this idea could be postponed indefinitely or rejected in the present state of affairs; which option would you choose? I mean, converting the dates the author regularly uses to Gregorian would require support from the editor or postprocessor. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, July 30, 2008 1:13 PM To: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime
Re: [whatwg] Expanding datetime
Ian Hickson wrote: On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really. Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals: http://microformats.org/wiki/machine-data XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them. DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata: http://www.w3.org/html/wg/html5/#custom Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement. -- Benjamin Hawkes-Lewis
Re: [whatwg] Proposal for a link attribute to replace a href
On Wed, 30 Jul 2008, Simon Pieters wrote:
There are also alternative suggestions, like making a contain any
element. Unfortunately, none of these end up working (e.g. for this
proposal, ap/a would create an unexpected DOM -- we'd have to
make /p end tags not optional when the next end tag was an /a,
which would be somewhat confusing).
The rules for optional end tags are already pretty confusing. I don't
think it's a problem to require /p when the p element is the last
child of an a element.
Ok. Fair enough. I have allowed a elements to surround other
(non-interactive) elements.
On Wed, 30 Jul 2008, James Graham wrote:
I think tableatr also causes problems; being able to link whole
table rows seems like one of the major use cases for this proposal.
Yes. I don't see how to fix that one.
Would the implementor feedback that global href is a bad idea still
apply if instead of global it was large set of elements where the
large set would explicitly not include things like form elements?
Yeah -- the problem isn't so much the number of elements, as the
complexity of doing a link. Resolving URLs, making it match
:link/:visited, handling clicks, handling base URLs, hover effects with
status information, etc. Links are hard.
On Wed, 30 Jul 2008, Simon Pieters wrote:
Perhaps HTMLElement should have a links collection to make it simpler to
write the script?
tr onclick=links[0].click()
I don't know that that is all that much better than
getElementsByTagName('a')[0], or even:
tr onclick=link(event) ... /tr
script
function link(e) {
var a = e.currentTarget.getElementsByTagName('a')[0];
if (e.target != a)
a.click();
}
/script
On Wed, 30 Jul 2008, Smylers wrote:
I don't think the JS is a big deal.
Compared to a href=..., using onlick events generally provides a
worse user experience, such as the status bar not being updated to
indicate a link's destination in advance of committing to navigate
there.
Sure, but that's ok, because the link is still visible and present as a
link in this case -- it's just that the user can click anywhere to
activate it instead of only on the text. I don't think that's a
particularly horrible user experience, I think it's fine. No?
On Wed, 30 Jul 2008, Russell Leggett wrote:
What about an alternative attribute like navigate instead of href. It
would not carry the full weight of the anchor tag, but would handle the 90%
use case. It would not allow for the same options as the a tag, and the a
tag would continue to work the same way that it has been.
The difficulties are in the basic linking ability, not the more esoteric
features, sadly.
On Wed, 30 Jul 2008, Kristof Zelechovski wrote:
By the current spec, the Anchor element is phrasing content, which is a
special case of flow content. Did you mean transparent content instead?
EC! I cannot see any inline content in HTML5, at least not in 3.4.1 where
content models are defined.
HTML5 has no inline or block concept, indeed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] input=datetime and unixtime?
I did some searching through the archives, but didn't find anything at all that talked about this. Out of curiousity, was there a reason that datetime doesn't store/send it's value as a unix timestamp? True, the standard unixtime unit is insufficient for representing a useful range of dates, but systems are gradually moving toward representing unixtime with a 64-bit integer. If there is a problem with handling 64-bit integers in browsers, it is easy enough to merely store it as a string, which can then be parsed trivially back into an int by the server, much easier than parsing a datetime string as currently specified would be. There is an obvious issue that you would lose the millisecond precision, but this may or may not be significant. ~TJ
Re: [whatwg] input=datetime and unixtime?
Tab Atkins Jr. wrote: I did some searching through the archives, but didn't find anything at all that talked about this. Out of curiousity, was there a reason that datetime doesn't store/send it's value as a unix timestamp? IIRC, one reason is or better graceful degradation in legacy user agents that don't support the datetime controls, and where no JavaScript based alternative available. In such cases, it's easier to get the user to enter a date in the format like -MM-DD, than it is to have them calculate and enter the number of milliseconds since the epoch. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Expanding datetime
[Warning: begin tirade, diatribe, fulmination, harangue, jeremiad, and/or philippic] At the very least, ensure that the range of times (dates, durations, intervals and times-of-day) and the granularity are well and rigorously specified. Ensure, also, that there is a Javascript mechanism to alarm, mechanically, when such element values exceed the specified envelope (I do not see such in the current text). If the browser cannot handle a datetime string of -0548-11-22 18:23:46,03276548901+3 (other-epochal, proleptic, locale-dependent and, I'm certain, annoying in several other respects), just make sure Javascript does something predictable and explicit. I can see arguments on both sides of the question: + Microformats and extra-UNIXian-epochs are needed and there are business cases Hawkes-Lewis alludes to such with the Disney link (http://en.wikipedia.org/wiki/Walt_Disney) Read: Copyright Issues - It's so painful as to require a document comparable to the entire HTML5 specification Previous postings have commented on datetime strings and ISO-8601 and look at that awful mess I used, above, as an example Strangely, there exists an argument for a crippling of capabilities. It goes like this: If a browser's Javascript is limited, JS files can support microformats, proleptic dates, Before-Common-Era dates, unique epochs and so on. However, the creation of such utilities will be hindered if the needs-case is nebulous. Failing to explicitly specify the HTML5 envelope will only increase that ambiguity (Well, it works most of the time, so why bother?). The question then becomes, Is the specification properly limited or ludicrous? I would claim that an epoch of 1970 (the traditional, UNIX epoch) is ludicrous just because so many luminaries started their existence before that moment (for example, me - ahem). On the other hand, I could understand a requirement that an epoch of no later than 1900, while limited, is at least proper (even in light of some locales' not adopting the Gregorian calendar until the 1930s). Just don't hinder the needs-case for somebody building the JS files (I repeat myself, but I did warn that this would be tediously hortatory). [end tirade - Thank you for your patience] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Hawkes-Lewis Sent: Wednesday, 2008 July 30 16:29 To: Ian Hickson Cc: 'WHATWG List' Subject: Re: [whatwg] Expanding datetime Ian Hickson wrote: On Thu, 24 Apr 2008, Henri Sivonen wrote: How do proleptic Gregorian dates before the Common Era fit into any of the use cases that states are used for in HTML? Insertion and deletion dates are contemporary. Date form widgets are meant for airline and hotel reservations and, hence, need to pick dates from the near future. The time element is meant for microformats, which means that it will be used for encoding current or near-future events dates. Right. Wrong. Microformats may also be used to mark up events that happened in the past and people who are dead. For example: http://en.wikipedia.org/wiki/Walt_Disney If HTML5 does not provide a way to specify datetimes BC, then the microformats community would be left in the boat they're already in of trying to fudge markup to encode datetimes BC. Little gained, really. Regardless of what elements are added to HTML5, I believe HTML5 needs a simple extension point where microformats can insert machine-parsable equivalents and expansions of human friendly data. Data types are by no means limited to those already covered by the HTML5 proposals: http://microformats.org/wiki/machine-data XHTML2 provides such an extension point with the (confusingly named) CONTENT attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content Such an extension point could meet the use-case of making datetimes BC extractable and also any use-case for far-future datetimes without requiring HTML5 to explicit specify calendar APIs for them. DATA-* is not yet such an extension point, since it is only to be used for private scripts not public metadata: http://www.w3.org/html/wg/html5/#custom Obviously, it would be /ideal/ if DATETIME could actually handle a range of dates useful for educational and research purposes as well as social networking and business and if schoolkids and academics didn't have to fall back on extension points and homebrew code, but I accept that it would inevitably be more work to spec and probably for user agent developers to ultimately implement. -- Benjamin Hawkes-Lewis
Re: [whatwg] The div element
On Thu, 28 Feb 2008, Geoff Pack wrote: Why does the HTML5 spec say The div element represents nothing at all? [http://www.whatwg.org/specs/web-apps/current-work/#the-div] Div clearly stands for 'division', as was specified in the HTML 3.2 spec: DIV elements can be used to structure HTML documents as a hierarchy of divisions. [http://www.w3.org/TR/REC-html32#div] So what gives - why is everyone so keen to claim that 'div' is meaningless? And why so keen on 'section', which is pretty much synonymous in this context. section and div have very different semantics. section describes a section of a document, e.g. a chapter or a scene. div is a generic element used for grouping and structure when there's nothing better to use. If we said it represented a division, then there would be nothing left over to represent nothing. For example, people want to do things like: div class=chart-control div class=chart-panel div class=toolbar div class=zoom-control ... /div div class=dates ... /div div class=legend ... /div /div div class=chart ... /div /div div class=timeline div class=background ... /div div class=active-indicator ... /div div class=scroller-control ... /div /div /div ...to represent something like the stock chart widget on Google Finance. These aren't divisions. They're nothing, just places to hang styles from because HTML isn't good enough to natively have a stock chart control. On Thu, 28 Feb 2008, Dave Hodder wrote: Personally I'd describe it more along the lines of: The div element is a generic way of representing document structure, but offers no further semantics. Where appropriate, elements with more specific meanings (such as section or aside) should be used instead. Use of the div element may be appropriate for extended features not covered by this specification, for example a new type of user interface control. I don't think the divs in the example above are representing document structure in anything more than the most technical of senses. On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: I'm still not clear to me how section/ is anything more than a div/. HTML4 said: The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents (http://www.w3.org/TR/html401/struct/global.html#edef-DIV). Isn't that the very thing that section/ is trying to do? Provide structure? I don't see that it offers anything over and above what div/s do now, except for confusing developers as to which is more appropriate to use. The difference is that section elements appear in the table of contents, basically. On Fri, 29 Feb 2008, Tab Atkins Jr. wrote: In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. (This isn't completely true, but it is true that the rank of headers only affects headers withint the same sectioning element.) Question to others: I think it is somewhat unclear what exactly the correct semantics are for section when it is encountered outside of an article. Since section is the most generic of the sectioning tags, there is a definite risk of it falling into the same hole that div is in. Where exactly should section be used when outside of an article, and when should we just default to the div? article isn't needed if there's only one article on the page, or if the page is part of a large set of documents forming a single article or book-equivalent. On Mon, 3 Mar 2008, Geoff Pack wrote: After following the discussion, I�m still not any clearer about the difference between sections and divs. But no matter. What I�m bothered about is not which to use where, but the description in the spec. I think it should be changed from: �The div element represents nothing at all.� To something like: The div element represents a document division. It can (also) be used as a generic block-level element If something represents both A and not-A, then it represents nothing, effectively, since you can't tell which meaning is being used at any one time. Hence, the div element represents nothing. Similarly, the definition of the span element should be changed from: The span element doesn't mean anything on its own... To: The span element represents an arbitrary span of text. The text itself represents the arbitrary span of text. The span element doesn't add anything to the meaning of the document on its own. That's what the spec is saying. Strangely enough, both the b and i elements begin: The .. element represents a span of text... Both of those sections immediately elaborate about the special characteristics that they introduce to those spans. -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] Thoughts on HTML 5
(Not all of this e-mail is covered in this reply. It's possible that I will reply to the same points in this e-mail multiple times, for which I apologise in advance.) On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: * I'm not sure what the section/ element offers over the div/ element. I thought the purpose of the div/ was to indicate a section of the page. If there's not a clear distinction between these elements, I don't see the need for a second one. Please see: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015506.html ...for a discussion on this matter. * I'm a bit unsure of the article/ element. As with section/, it seems only vaguely different from div/ and too focused on solving the question of what markup to use for a blog. Blogs and forums and news articles, yes. Those are quite a big use case on the Web. :-) * The aside/ element really pushes the boundaries of marking up literary devices. I'm not sure enough web developers know what an aside actually is. Short asides are typically indicated by parentheses and I don't see any reason not to keep doing that (seriously). Any element that requires someone to ask an English teacher when it should be used is probably a bad idea. There are a lot of asides on the Web. Ads, side notes, indeed almost anything in a sidebar other than navigation, etc. * The dfn/ is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn't, don't feel bad, most people won't get it. Again, any element that leaves people scratching their heads probably isn't necessary or useful. It's an element that I use a lot in HTML5 itself. I agree that it's not a big target audience, as it were, but since it's already implemented it's a lot easier for us to add it than it would be to add other elements with little potential usage. * Speaking of confusing, I've read the section about the meter/ element five times now and still have no idea what it's used for. Do the examples not help? * I'd like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now). Sadly the problem is that while everyone agrees on the need, nobody agrees on exactly what the profile of HTML that should be allowed is, and short of including an entire schema language, there doesn't seem to be a good solution. The spec now gets around this by just providing a generic mechanism and relying on the scripts to implement whatever restrictions they want. * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data related to an element. I'd propose a reldata attribute (short for related data) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). We've added data-* for this. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Sat, 1 Mar 2008, Nicholas C. Zakas wrote: As there is also another thread going on about section/, I don't want to repeat all of my comments here, but suffice to say that I don't see why I'd ever use section/ when I get implicit sections by using hn/ elements. Writers are used to headings indicating sections, and don't really think of a section as anything on its own. I can understand the use of article/ as semantically indicating that the area contains information rather than markup, but I think section/ is overkill. I think it won't be used by everyone, but some people have indicated a clear desire to not have to worry about the numbering of headers. I understand your reasoning for the aside/ element, perhaps this is another element that is suffering from the wrong name. Most of web developers have no idea what an aside is let alone when to use one. I know that acronym/ was removed because it confused web developers. Given that this is the same audience, the ones who couldn't figure out the difference between an acronym and an abbreviation, do you really think that aside/ will get used? Perhaps it would better be named callout/? sidebar might be ok, but I wanted to avoid being too specific about the presentation in the name. (acronym was removed because it's redundant with abbr.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Sat, 8 Mar 2008, Nicholas C. Zakas wrote: From: Shannon [EMAIL PROTECTED] Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Call it note. It may sound crude but it's hard to mistake its meaning. Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! note and callout aren't really generic enough. e.g. in HTML5 aside would be used for both the notes and the examples in the spec, but note would only sound like it was ok for the notes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
Ian Hickson wrote: On Sat, 8 Mar 2008, Nicholas C. Zakas wrote: From: Shannon [EMAIL PROTECTED] Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Call it note. It may sound crude but it's hard to mistake its meaning. Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! note and callout aren't really generic enough. e.g. in HTML5 aside would be used for both the notes and the examples in the spec, but note would only sound like it was ok for the notes. I think web developers would prefer pointless, distraction, wasteofspace or bossmademedoit. Shannon
Re: [whatwg] Rép : time and meter elements
On Sat, 31 May 2008, David Latapie wrote: Ian wrote: | address | nameJohn Hopkins/namebr | Phone: (359) 555-1701 | /address Notwithstanding what I consider misuse of br [...] Indeed, I do not see any semantic value in br at all. As for poetry and lyrics (a common example of when to use br), this should be handled with its proper namespace anyway, since appearance is part of the meaning (the most outstanding example being Appolinaire�s Calligrammes). Some poetry is visual, for which we have pre, but not all poetry. Consider for instance the poems read by Ani DiFranco on her albums. Clearly, given that her poems here are read out and not conveyed in a visual medium, they are not primarily visual. This is the kind of poetry for which br would be an appropriate typographical tool. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Thu, 12 Jun 2008, Jorge Bay Gondra wrote: I was trying to imaging how it would be to build a site, and I realized that, in the case of site with 2 nav bars (typically 2 sidebars) there's not a way to specify which is the main sidebar and which is accessory... What do you think about specifying hierarchy for navs elements? On Fri, 13 Jun 2008, James Graham wrote: Arguably the outline algorithm already does this, since it places nav elements in a hierarchy along with other sections. For any case not covered by the outline algorithm I think that there would need to be some very strong use cases to add explicit markup here; what kind of UA features did you have in mind, and how well would they work if the markup was missing or incorrect on most pages? I agree with James here, what is the use case? On Thu, 12 Jun 2008, Jorge Bay Gondra wrote: Note: In the nav sample ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-root.html#the-nav) that includes several places with links, should be a good idea that the header and footer list of links have to be represented in an unordered list ul..., and not in a paragraph (!?), do you agree? Doesn't really matter either way. Do can do whatever you like. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Signatures
Over the years a number of e-mails have been sent to the list about signatures and other public key cryptography topics, most of which are quoted below. For a number of reasons, not least of which my lack of expertise in the area, the size of the HTML5 spec today, and the low level of demand for these features, I have decided to not cover this topic in HTML5, and instead rely on other groups to define these features. I include a representative sampling of the e-mails sent to the WHATWG on the topic below, so that if anyone wishes to work on this topic, they can use this feedback. I encourage people interested in this topic to approach the IETF, where work on these issues has historically taken place. On Sun, 29 Oct 2006, Anders Rundgren wrote: It is equally interesting that W3C intends to start a new browser authentication WG but have excluded digital signatures and key provisioning from the charter in spite of the fact that about 10M people today have to use proprietary browser-plugins in order to get their work done. Maybe an answer to that is that this is only happening in the EU which in this particular space is roughly 5 years ahead of the US government and financial industry. On Mon, 30 Oct 2006, Michael(tm) Smith wrote: The use of proprietary mechanisms (mostly ActiveX controls) for digital signatures is common in Korean sites as well, including Korean government sites. On Mon, 30 Oct 2006, Anders Rundgren wrote: That's right. They sure are proprietary; I was not even able to get the Korean e-goverment signature spec since it is secret! On Tue, 31 Oct 2006, Channy Yun wrote: Korean mechanism is same with general pki's. Its structure has been followed by pki standards and browser user-interface for certificates. The different things has own 128bit cryptography algorithm so called SEED and adds digital signature for messages to be legal authorizing. This spec is not secret and gives in http://www.rootca.or.kr/maine.jsp On Mon, 30 Oct 2006, Anders Rundgren wrote: I may have been careless but I could not find the spec of the activeX control (or similar) that is what I refer to as the proprietary solution. I may also have confused Korea with Hongkong who definitely claimed that their scheme requires an NDA. The same goes for the Australian scheme which is not public. BTW, the Swedish and Norwegian government's signature systems are also secret since they are developed by banks. On Wed, 1 Nov 2006, Channy Yun wrote: As you said, we may not get sufficient informations to standardize digital signature. But, in case of Korea, I'll sufficiently give them. The spec. and interface are almost standardized by governmental rules to all vendors. In Korea, the own cryptic algorithm has been encouraged, so vendors couldn't use browser-implemented things such as DES. This is first reason to use activex controls. Second is for digital signature. Legally, all data must be signed by user's key. When the money is sent, it needs to know who sends the money. So activex control has almost same user interface with browser's certificate manager. When an user enters an internet banking site, activex are embedded. User's data by action go to activex control and are encrypted by SEED and signed by user's key. Encrypted and signed data gives hidden form in web page again. When an user submit it, the data were transferred to web server. The server-side application decrypts and verifies the data and proceeds proper actions. Web server transfers the web page by requested actions. First thing is not standardized. National algorithm such as SEED or Camella is problems between browser vendor and its governments. Second can be done such as (re)issue and revocation of personal certificates, the digital signature such as old crypto.sign.Text(). As following is one of this efforts. http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt On Wed, 1 Nov 2006, Channy Yun wrote: As I said in other thread, I think digital signature must be standardized for secure and legal assurance of form data and I respect your issuing and great jobs. But, we can simply think this issue in range of this group. Most of forms directly go to web server via urlencoded. If some indicators are given, browsers can execute signing process. For example, form name=sendmoney action=/send.cgi signed=signed input type=text name=dollars value=3.00 input type=text name=account values=1234567890 input type=submt value=Sending Money! /form When an user clicks submit button, the dialog box will be opened for selecting the private certificates to be signed. Server can understand form data and attached signatures signed by browser via SSL. Or it can be applied each forms. input type=text name=dollars value=3.00 signed=signed Anyway it is browser's the function of digital signature such as
[whatwg] The dialog element and related topics
On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: * 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. On Wed, 14 May 2008, Krzysztof Żelechowski wrote: I recommend transcript because it refers to a conversation that has been put down, as compared to a live conversation (I do not recommend introducing the latter, of course, as HTML is not live). On Wed, 14 May 2008, Smylers wrote, regarding the transcript idea: However many things in webpages are things which have been written down! This is specifically a transcript of some speech -- not a transcript of commands typed at a computer prompt, nor an exam transcript, nor any other kind of transcript. So focusing on the thing being transcribed, the speech, seems more sensible; that it has been written down is something which will be readily apparent to anybody reading it! On Wed, 14 May 2008, K�i�tof �elechovski wrote: Commands typed at a computer prompt do form a conversation between the commander and the executor (if the executor responds - otherwise it is good old CODE). On the other hand, a speech is closer to a monologue (soliloquy). On Wed, 14 May 2008, Smylers wrote, regarding the talk idea: Indeed; as a noun a talk seems to refer to a presentation more often than the action of talking. talking would be less subject to misinterpretation, but the gerund form makes an awkward tag name. On Wed, 14 May 2008, K�i�tof �elechovski wrote, regarding converse: converse is more an adjective like opposite to me. Which is even more awkward. On Wed, 14 May 2008, Tab Atkins Jr. wrote, regarding talk: Honestly, though, are we concerned that people will think a talk element in html refers to a slideshow? The ambiguity of dialog occurs because there is a very reasonable and natural interpretation for the element name within the context of web applications that happens to be completely wrong. talk, while certainly ambiguous in some ways, is extremely clear within the context of a web application. There is no other major existing entity or idea with the same or similar name for it to clash with. On Wed, 7 May 2008, Simon Pieters wrote, regarding dialogue: Also see http://forums.whatwg.org/viewtopic.php?t=24 for discussion about dialog vs dialogue. On Wed, 14 May 2008, Mikko Rantalainen wrote: Ian Hickson wrote: Experience with language= on script suggests that many authors have serious difficulties spelling words that contain the gu letter pair. I, too, think that the word dialog sounds more like dialog window or dialog box than a dialogue. I'd prefer dialogue over dialog for following reasons: - cannot be confused with dialog box or dialog window - the dialogue tag would probably most often be generated by CMS system or authoring software so spelling errors are not such a big issue - dialogue is pretty seldom used feature and I believe it doesn't deserve any shorter tag If dialog is used instead of dialogue then it should be designed in a such way that it can be used for dialog box in addition to dialogue (e.g. chat) in the future. On Wed, 14 May 2008, Tab Atkins Jr. wrote: I severely doubt this is possible or desirable. It would make it *more* confusing, I think, if dialog was meant for dialog boxes *and* marking up conversations. Just to throw out yet another possibility, how about convo? I don't like it too much, but it at least avoids most of the issues that plagued the other submissions. I'm generally convinced that dialog is an okay choice for this, but if we *were* to change, I at least want to make sure it's something I can get behind. My personal favorite alternate suggestion so far has been cl. Short and a little confusing? Maybe. But it has the benefit of being unambiguous and parallels existing tags with similar syntax. But meh, it's probably not quite right, as dialog isn't meant to be illustrating a conversation list, but rather is a list illustrating a conversation. On Wed, 14 May 2008, Charles wrote: My personal favorite alternate suggestion so far has been cl. On Thu, 15 May 2008, Mike Wilson wrote: 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
Re: [whatwg] Fake Code
On Wed, Jul 30, 2008 at 2:42 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 29 Jul 2008, Garrett Smith wrote:
var s = ;
test(document,
function (a) { s += enter + a + \n; },
function (a) { s += exit + a + \n; });
s
The output was what I expected. There were no syntax errors. Could you
elaborate on what else you think is wrong other than the do?
Ah, makes more sense now. The extra 'do' threw me off (I was also
tired when I first looked at it). It would need an identifier to avoid
confusing the parser, though (either that or assign it in an
assignment statement). It looks like you're calling the function
'test'.
function walkTree(root, enter, exit) {
var node = root;
start: while (node) {
enter(node);
if (node.firstChild) {
node = node.firstChild;
continue start;
}
while (node) {
exit(node);
if (node.nextSibling) {
node = node.nextSibling;
continue start;
}
if (node == root)
node = null;
else
node = node.parentNode;
}
}
}
Garrett
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] figure element feedback
figure was changed some time back to allow any content and to allow the legend to be omitted. At the time this was done as part of a content model overhaul and so I forgot to respond to some of the figure feedback. (I haven't quoted most of the feedback asking for this below, since many of the same points were made several times.) On Mon, 27 Nov 2006, Michel Fortin wrote: To me, a figure contains illustrative content attached to a document. It may be an image, a code sample, or a snippet of another document used as an example. I think it's important we do not try to narrow too much what can and what cannot be contained in a figure; that's the job of the author do decide. Done. Moreover, I don't think the caption should be mandatory. I know that the primary reason for including a figure element is to have a way to put captions on things, but figure as a simple container for illustrative content has value too. For instance, I would gladly use figure to denote HTML snippets in the following document of my own website: http://www.michelf.com/projects/php-markdown/concepts/ Would this be a valid usage? (Of course, according to the current spec: no. But should it be?) It's not valid. This one in particular: http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html ...suggests we may want to have multiple legend elements per figure, to allow for a caption and photo credit to be given. What do people think? Would some other way of inline giving photo credit metadata be better? I think that could be useful. But my opinion is that it'd probably be better to find a way to do this in the same manner for table captions too. (A table caption citing the source for its data is quite common.) I think it'd be wiser to do this using inline elements inside legend or caption. I haven't added credit yet... I'd rather see how figure fares as is before adding more stuff. On Tue, 28 Nov 2006, fantasai wrote: I'd suggest using address, e.g. figure img addressPhoto by Mariel/address /figure figure img captionCarcassonne/caption addressPhoto by Mariel/address /figure Yeah, that might make sense, even. Right now the content model allows it, so long as the legend comes last (or first), so feel free to experiment with this. On Tue, 28 Nov 2006, Benjamin Hawkes-Lewis wrote: Mere attribution is not contact information. If all attributions included a link to the creator's or copyright holder's webpage, or an email address, that would work, but there's no guarantee they will. Such usage dilutes the meaning of address/. footer could work too, to some extent. I mean, it's not right per spec now, but if people experiment with it I'd be interested in hearing of the results, they wouldn't certainly influence how the spec develops. On Tue, 28 Nov 2006, L. David Baron wrote: On Tuesday 2006-11-28 01:49 +, Ian Hickson wrote: figure img ... legend ... /legend /figure There are special rules for what to do with fallback that basically make the caption disappear (though of course this won't happen in legacy UAs). I'm assuming the rules you're referring to are those at: http://www.whatwg.org/specs/web-apps/current-work/#figure0 Are these rules worth the complexity they add? I think in many cases they may actually be harmful. In particular, authors who aren't thinking much about fallback content may be writing captions that would be the most useful fallback content available. Insisting that those captions not be available when there is no fallback content seems like a bad idea. This is all gone now. On Tue, 28 Nov 2006, David Walbert wrote: This one in particular: http://politics.guardian.co.uk/homeaffairs/story/0,,1806799,00.html ...suggests we may want to have multiple legend elements per figure, to allow for a caption and photo credit to be given. What do people think? Would some other way of inline giving photo credit metadata be better? Yes, I think a separate element for credit would be great. The caption and credit are functionally different. A caption tells the reader why an image has been included in the page; a credit tells where it came from. I've done a quick survey this morning of magazines and textbooks around the office, and confirmed my suspicion that typically, caption and credit are displayed and styled separately. I think they would be more often separated on the web if average web design was as careful and competent as average print design. They look the same on the Guardian's website, but most often, the caption is small sans-serif text placed directly under or beside the photo with little margin, and the caption is in larger text slightly farther below the image. If the credit is in the same visual block with the caption, it's often presented in a different font. The
