Re: [whatwg] Proposal for a link attribute to replace a href
Markus Ernst wrote:
Anyway, why do you suggest a new attribute rather than making the
existing href attribute global?
Because I think some current and depreciated tags still use href for a
different purpose (base for one). A global attribute should be unique.
I don't really mind what the attribute is called.
Anne van Kesteren wrote:
We have a FAQ entry on this -- quite common -- request:
http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F
Hope that helps!
I'm happy to see it's a common request but I really hope the FAQ entry
doesn't represent a final decision. I strongly disagree with its
conclusions, so I'll address each:
FAQ: * It isn't backwards compatible with existing browsers.
Not entirely true. I quote from the same FAQ:
What about Microsoft and Internet Explorer?
HTML 5 is being developed with IE compatibility in mind. Support for
many features can be simulated using JavaScript.
So 'backwards-compatibility', as defined by the same document, can be
achieved by using javascript to walk the DOM and add
'window.location(node.getAttribute('link'))' to the onclick handler of
any nodes with a link attribute. I have done a very similar thing before
to implement :hover on non-anchor elements in IE. Of course an author
wouldn't have to use this new attribute at all so
backwards-compatibility is the designers choice, not an issue with the
proposed attribute.
FAQ: * It adds no new functionality that can't already be achieved
using the a element.
Absolutely not true. A global attribute offers several features that a
does not - most importantly nested links and the ability to hyperlink
block and interactive elements without breaking validation.
FAQ: * It doesn't make sense for all elements, such as interactive
elements like input and button, where the use of href would interfere
with their normal function.
As long as the spec is clear about which actions take precedence then
this is not an issue. The spec should assume that if an author puts a
link on a form element then they are *deliberately* interfering with its
normal function. Trying to protect authors/users from their own bad
choices is a very 'Microsoft' way of thinking and not really appropriate
for spec targetting web authors. There might be good reasons for doing
this that are not immediately obvious.
FAQ: * Browser vendors have reported that implementing it would be
extremely complex.
I find this claim incredible. How is a global link/href any more
difficult than the existing implementations of onmouseup/down/whatever?
It's basically the same thing - only *simpler* (no scripting, events,
bubbling, etc).
So on all counts I find the claims in the FAQ incorrect and urge the
WHATWG and browser vendors to reconsider the inclusion of a global link
or href attribute.
Shannon
Re: [whatwg] Proposal for a link attribute to replace a href
W liście Shannon z dnia czwartek 28 lutego 2008: FAQ: * It adds no new functionality that can't already be achieved using the a element. Absolutely not true. A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. In my opinion this would be an important problem. How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. -- Paweł Stradomski
Re: [whatwg] several messages about figure and related subjects
Dnia 27-02-2008, Śr o godzinie 08:06 -0500, Michel Fortin pisze: Now, suppose you have this: pA header looks like this in your browser:/p h1Some text!/h1 ... unfortunately, the h1 here isn't a real header in the document: it's an illustration of a header (ah-ha: figure!) which can't be removed from te flow of the document (oops, can't use figure). There's no rational way to markup this with the current wording of the spec; abusing figure is the most reasonable option I can find: pA header looks like this in your browser:/p figureh1Some text!/h1/figure The problem being that figure needs the ability to be moved around without changing the meaning of the document, so the markup above would be non-conforming because the sentence just makes no sense if you put the figure elsewhere. Perhaps figure could have an optional anchored attribute to indicate it belongs to a specific point in the document. If the page has a header, you can refer the reader to its ordinary header instead. The purpose of headers is to make looking around the page easier; your sample header would be a distraction if it is styled like a normal header and would not make a good demonstration if it is not. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 28-02-2008, Cz o godzinie 23:18 +1100, Shannon pisze: Markus Ernst wrote: Anyway, why do you suggest a new attribute rather than making the existing href attribute global? Because I think some current and depreciated tags still use href for a different purpose (base for one). A global attribute should be unique. I don't really mind what the attribute is called. BASE is invisible so it does not matter. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Dnia 27-02-2008, Śr o godzinie 23:25 +1100, Shannon pisze: ---LINK with block-level or interactive content--- This proposal would circumvent A's main limitation which is its requirement to not wrap block-level elements or 'interactive' content. The HTML5 draft requires it wrap 'phrasing content' (essentially paragraphs) and not wrap 'interactive' content (such as other hyperlinks) however I see no reason why a link attribute should require these limits. Links would simply cascade as in the following example: table link=alphabet.html title=Alphabetical List tr tdA/td tdB/td td link=c.html title=More about CC/td tdD/td /tr /table Tables should be used to present tabular data. Tabular data is something the user may want to meditate or to copy; their content cannot be grasped in a glance. Hyperlinked text should be a concise description of the content of the other page; a table does not meet that requirement. This design violates the least surprise principle. In the example above clicking anywhere on the table except 'C' brings up a generic page, whereas 'C' has dedicated content. The following nested links would also be valid: span link=foo.htmlclick anywhere on this line except b link=bar.html title=Go to bar insteadhere/b to visit foo./span It would be difficult to style a hyperlink within a hyperlink; moreover, a hyperlink that contains another hyperlink is not concise, see above. Chris
Re: [whatwg] Proposal for a link attribute to replace a href
Paweł Stradomski wrote: W liście Shannon z dnia czwartek 28 lutego 2008: FAQ: * It adds no new functionality that can't already be achieved using the a element. Absolutely not true. A global attribute offers several features that a does not - most importantly nested links and the ability to hyperlink block and interactive elements without breaking validation. In my opinion this would be an important problem. How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. I really like this idea too. I have no idea why anyone would want to nest links, whatever the parent element is. I don't understand why buttons should not be allowed an href, obviously when the button or input is to submit a form (ie. explicitly having type=submit as an attribute) it shouldn't be allowed but I'd find it useful where I've had to style a collection of links and inputs to be similar, for example the steps for a checkout process: currently I have this: div class=steps a href=/basket.html class=basket-stepBasket/span a href=/checkout.html class=current checkout-stepCheckout/a input type=submit class=confirm-step value=Confirm / span class=payment-stepPayment/span /div but it could become: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. There are plenty of other places where I'd like to put an href on an input or button within a form. For example when performing sub-tasks via a query string before a form is submitted, I think a button is more appropriate than an anchor tag (which is normally associated with navigating to another page). How web developers use it is up to them as always. It's up to the individual to use HTML appropriately so I think this would be a nifty addition to the repertoire. Cheers, Rob
[whatwg] Thoughts on HTML 5
I had posted this on my personal blog: http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I join the mailing list to continue the discussion, so here it is: I've just finished taking a look at the working draft of HTML 5 and thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution of HTML 4, which has both its good and bad points. Accordingly, there are both good and bad parts of the specification. My thoughts are as follows: * I almost laughed when I saw the irrelevant attribute. First, because that's a word that web developers throw around a lot and second because I can't imagine ever using it. The spec says, When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the irrelevant attribute specified. If it's not relevant, why is it in the page in the first place? Further, do you know how many people will spell this wrong 100 times before they spell it right? Unless there's a deeper meaning or requirement behind this attribute, I think it's just a waste of a section. * The scoped attribute is a welcome addition to the style/ element. Being able to apply styles to just a section of the page is something that I've personally struggled with mightily. I'm glad to see a logical solution. * 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. * I like the nav/ element. It's helpful in a number of ways to have an area marked as being for navigation. The accessibility implications alone are outstanding. * 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. * 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. * 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. * The ping attribute on the a/ element is a stroke of pure genius. We've been left hacking solutions for click monitoring for way too long. * 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. * 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. * The video/ and audio/ elements bring some much-needed sanity to the embedding of media into web pages. * The async attribute is a welcome addition to the script/ element, allowing it to perform non-blocking code execution. Realistically, this is useful only for a small number of JavaScript files as there are often dependencies between JavaScript files. The entire specification is insanely long and, interestingly, covers much more than just markup. It also covers related and unrelated DOM interfaces as well as additional JavaScript APIs. I think it's heading in the right direction, but HTML 5 does miss some things that seem to be issues that should be addressed: * 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). * 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
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] wrote: Lachlan had commented that irrelevant could be changed dynamically to indicate parts of an application that may be relevant only during particular points in time. I don't see how this is any different from hiding content that isn't necessary. Presumably a non-visual UA could use the irrelevant attribute to distinguish content that was not relevant at the current time from content that was merely being hidden from graphical UAs. I seem to remember (but I am far from being an expert) that currently aural browsers ignore display:none content and so best-practice for adding additional text for aural UAs is to use CSS positioning to move it out of the viewport. @irrelevant seems to provide a way to move away from this kind of crazy hack. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Thoughts on HTML 5
Screen readers currently ignore elements with styles of display:none and visibility:hidden. In order to hide elements from the screen but allow screen readers to see them, we typically use tricks such as text-indent:-1 and such. I would like something to indicate that text should not be rendered by the UA but still remain accessible. Content that should be available to screen readers but not have a visual representation is, in fact, relevant. It's relevant in that it gives additional information to non-sighted users that is probably visually indicated to those who can see. If accessibility is the point of the irrelevant attribute, then it fails. -Nicholas [EMAIL PROTECTED] wrote: Lachlan had commented that irrelevant could be changed dynamically to indicate parts of an application that may be relevant only during particular points in time. I don't see how this is any different from hiding content that isn't necessary. Presumably a non-visual UA could use the irrelevant attribute to distinguish content that was not relevant at the current time from content that was merely being hidden from graphical UAs. I seem to remember (but I am far from being an expert) that currently aural browsers ignore display:none content and so best-practice for adding additional text for aural UAs is to use CSS positioning to move it out of the viewport. @irrelevant seems to provide a way to move away from this kind of crazy hack. -- 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
W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). -- Paweł Stradomski
Re: [whatwg] Proposal for a link attribute to replace a href
On 28/02/2008, Shannon [EMAIL PROTECTED] wrote:
http://wiki.whatwg.org/wiki/FAQ#Does_HTML5_support_href_on_any_element_like_XHTML_2.0.3F
So 'backwards-compatibility', as defined by the same document, can be
achieved by using javascript to walk the DOM and add
'window.location(node.getAttribute('link'))' to the onclick handler of
any nodes with a link attribute. I have done a very similar thing before
to implement :hover on non-anchor elements in IE.
I imagine the script would have problems with incremental loading - if
someone clicks a link before the page has finished loading and before
the script has executed, then it won't work. Is there a way to avoid
that problem and make it work as well as a real implementation?
There are also tools like search engines that need to recognise links
and can't be fixed by compatibility scripts. (Fortunately it's much
easier to upgrade all the world's search engines than all its web
browsers, so this is a less significant issue than with browsers.)
A global attribute offers several features that a
does not - most importantly nested links and the ability to hyperlink
block and interactive elements without breaking validation.
Are there cases where div ...a href=... style=display:block;
width:100%; height:100% ... /a/div is not adequate for making
block links?
FAQ: * It doesn't make sense for all elements, such as interactive
elements like input and button, where the use of href would interfere
with their normal function.
As long as the spec is clear about which actions take precedence then
this is not an issue.
Having to make the spec clear is an issue :-)
It would take quite a bit of effort to design and specify the feature
in sufficient detail, and to write test cases, and to update the spec
in response to implementor feedback about what would cause them fewer
problems. That is all much harder when the new feature interacts with
a lot of existing features (inputs, buttons, image maps, iframes, DOM
events, etc), compared to something fairly self-contained (like
video).
How is a global link/href any more
difficult than the existing implementations of onmouseup/down/whatever?
It's basically the same thing - only *simpler* (no scripting, events,
bubbling, etc).
As far as I'm aware, HTML elements currently have at most one default
click-event handler and any number of DOM handlers. The new link
attribute wouldn't be a DOM event handler (since it ought to behave
much more like a href), so it would either be an entirely new type
of event handler or it would break the assumption that there is a
single default handler, and I can imagine that that would cause
difficulties. (But I have no implementation experience so I could be
entirely wrong.)
There are cases like
button type=submit link=... onclick=event.preventDefault()
button type=submit link=javascript:event.preventDefault()
a href=1 link=2 onclick=window.location=3
a href=1 link=2 onclick=window.location=3; return false
etc
where the interaction between several aspects of the event model would
have to be defined (and implemented and tested), requiring some new
complexity on top of the current href+onclick model.
Another issue is that a href has a number of other attributes for
links, and it would be bad design if a generalisation of href didn't
allow those attributes on other elements. That includes 'target'
(conflicts with base target, form target), 'type' (conflicts with
style type, script type, embed type, object type), 'media'
(conflicts with style media, link media), etc.
Is there a nice way to solve those conflicts? Renaming the link
attributes (the same as renaming 'href' to 'link') would be confusing
to people who already know HTML, and it would be hard to find good
names that aren't used already. Defining lots of exceptional cases for
certain attributes on certain elements would make the language harder
to understand and implement and test. Defining exceptions for a
category of 'non-visible elements' (script, style, etc) wouldn't work
since script style=display:block is not non-visible. I'm not sure
how this could be made to work well.
Shannon
--
Philip Taylor
[EMAIL PROTECTED]
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] wrote (with snippage): * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I was confused by the name of the dialog element in exactly the same way you were, originally thinking it was to do with pop-up dialogue boxes. The HTML 4 spec states: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. ... which I presume influenced the addition of this element. If there is a lot of dialogue marked up on the Web it deserves its own element, if not I guess DL could be considered to stand for dialogue list in addition to definition list. * 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). I'm not entirely sure I understand, but if you want to further define the semantics of an element or make it more specialised, another group has put forward the idea of a role attribute http://www.w3.org/TR/2007/WD-xhtml-role-20071004/. Regards, Dave
[whatwg] When closing the browser
I made a quick look through the HTML 5 Working Draft table of contents, as well
as Anne's differences document and went looking through
http://www.w3.org/html/wg/html5/#processing2 the changes on the network and
processing models to see if this was covered or not, but didn't see it. I
probably missed it, but noticed something today that I was fooling around with
some years ago and wondered if it has been addressed.
The user opens a web application as one of many tabs in a web browser. They
then, either within the application window, accidentally hit CTRL W (or its Mac
equivalent), or from the operating system, issue a close application command.
Most apps (as opposed to the more passive browsers) detect that new content
has been developed and in is jeopardy of being lost and therefore prompt the
user to the status of this possible data loss. The browser, unless I'm missing
something, seems to have a different status within the OS and just closes
without ceremony.
The way I've handled this is the past is to have an onunload script associated
with the body: onunload=if (confirm('Save before quitting')) (SaveIt());
where SaveIt is some magic function which writes to disk (I understand that
such a technique will standardize writing to local drive space in HTML5). I
also understand that there will be ways of overriding the default definitions
of CTRL-W etc. so that the developer may change these unpleasantries inherited
from the browser. However, in the case of the solution using onload/confirm,
(if you're not averse to using IE and looking at VML then see
http://srufaculty.sru.edu/david.dailey/grapher/grapher.96.html for an example)
, you have two choices: save and cancel -- cancel terminates without saving,
save terminates after saving.
Has this group or HTMLWG yet decided on a way of preventing accidental loss of
work for web applications in a way similar to how applications handle the
situation?
cheers,
David
Re: [whatwg] Proposal for a link attribute to replace a href
On Thu, Feb 28, 2008 at 1:44 PM, Paweł Stradomski [EMAIL PROTECTED] wrote: W liście Robert O'Rourke z dnia czwartek 28 lutego 2008: Paweł Stradomski wrote: div class=steps input href=/basket.html class=basket-step value=Basket / input href=/checkout.html class=current checkout-step value=Checkout / input type=submit class=confirm-step value=Confirm / input type=button disabled=disabled class=payment-step value=Payment / /div If I could use one (or at least fewer types) of elements it would make cross-browser styling easier. You're breaking element semantics here. inputs are for form input elements - text fields, checboxes etc. The above would make those inputs text fields, as you didn't spcify the type. Now how can an input be a link? It's supposed to accept user text, not to point to some other resource. Activating an input (by clicking on it etc.) should just make it start accepting typed text, not make the browser jump somewhere else. Presentation/style should follow the semantics, not the other way round. After more thinking I lean towards Krzysztof's point of view, href as global attribute is a bad idea. I guess it's in the FAQ for a purpose, so EOT for me (of course I'll accept and respond to off-list e-mails). -- Paweł Stradomski Nod to Pawel. A workaround would be to custom-style your buttons so that you can match the links to their appearance. I override default button patterning completely in my pages for precisely that reason (also so they fit in the color scheme better). It's easy enough to style a link in the same fashion (easiest of all when you have proper inline-block support).
Re: [whatwg] The div element
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] snip 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. Regards, Dave
Re: [whatwg] Thoughts on HTML 5
Yes, I believe the dialog/ element is supposed to be a disambiguation of the
dl/ element, which has previously been used for both conversations and
definition lists. It makes sense to have separate ones since there's no way to
tell what a dl/ represents now. That being said, I still feel the tag name
dialog is too confusing to use. Perhaps the role attribute would be
appropriate to use on dl/, such as dl role=conversation/?
As for my suggestion of reldata, my intent is to use the attribute for any
type of data related to the element. The role attribute is intended to be
used (from my understanding) to designate what role the element is playing on
the page. This is not an appropriate place to put extra data that isn't
necessary for the rendering or understanding of the element. My thought is
doing something like this:
div id=whatever reldata={clicks:1,track:true}
The data format could be whatever someone wants, plain text, structured text,
JSON...whatever you need. The point is to have a common place to dump extra but
related data that isn't important to the understanding of the element. I often
use custom attributes for this now, but it would be nice to have an official
attribute for this purpose.
-Nicholas
[EMAIL PROTECTED] wrote (with snippage):
* I understand the concept of the dialog/ element but it's named
completely wrong. The point is to markup a conversation between two or more
parties. The problem is that the word dialog, when in used in user
interfaces, refers to small windows that can be interacted with. When I first
read about this element, I assumed it was a way to indicate that part of the
page is a dialog window outside of the normal flow of the document (which I
thought was cool). After reading the rest, I was disappointed to find out that
wasn't the intent. I'd rename this element as conversation/ or discussion/
to avoid such misunderstandings.
I was confused by the name of the dialog element in exactly the same
way you were, originally thinking it was to do with pop-up dialogue
boxes. The HTML 4 spec states:
Another application of DL, for example, is for marking up
dialogues, with each DT naming a speaker, and each DD containing
his or her words.
... which I presume influenced the addition of this element. If there
is a lot of dialogue marked up on the Web it deserves its own element,
if not I guess DL could be considered to stand for dialogue list in
addition to definition list.
* 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).
I'm not entirely sure I understand, but if you want to further define
the semantics of an element or make it more specialised, another group
has put forward the idea of a role attribute
http://www.w3.org/TR/2007/WD-xhtml-role-20071004/.
Regards,
Dave
[whatwg] ARIA (was: Re: Thoughts on HTML 5)
[EMAIL PROTECTED] wrote:
snip
As for my suggestion of reldata, my intent is to use the attribute for any type of data
related to the element. The role attribute is intended to be used (from my
understanding) to designate what role the element is playing on the page. This is not an
appropriate place to put extra data that isn't necessary for the rendering or understanding of the
element. My thought is doing something like this:
div id=whatever reldata={clicks:1,track:true}
The data format could be whatever someone wants, plain text, structured text,
JSON...whatever you need. The point is to have a common place to dump extra but
related data that isn't important to the understanding of the element. I often
use custom attributes for this now, but it would be nice to have an official
attribute for this purpose.
It sounds like the two attributes would be complementary, with role
defining the tag as a whateverwidget, and reldata describing the
initial state and properties of the widget.
I don't know if you've seen the recent Accessible Rich Internet
Applications http://www.w3.org/TR/wai-aria/ draft? (There's also a
primer at http://www.w3.org/TR/wai-aria-primer/.) It describes a
number of standard states that can be added to custom controls. Rather
than potentially fitting multiple values into a reldata attribute, it
defines a host of attributes beginning with aria-. Example:
span role=checkbox aria-checked=trueFoo/span
I believe a number of script libraries (Dojo for example) plan on
supporting ARIA. Firefox has some ARIA support already.
The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it
should clarify the relationship (or non-relationship as it is at
present), even if it's only a brief mention in section 1.1.
Regards,
Dave
Re: [whatwg] When closing the browser
David,
The onbeforeunload event handler can be used in this manner. See these posts:
http://www.nczonline.net/archive/2006/3/311
http://www.nczonline.net/archive/2006/3/312
-Nicholas
I made a quick look through the HTML 5 Working Draft table of contents, as well
as Anne's differences document and went looking through
http://www.w3.org/html/wg/html5/#processing2 the changes on the network and
processing models to see if this was covered or not, but didn't see it. I
probably missed it, but noticed something today that I was fooling around with
some years ago and wondered if it has been addressed.
The user opens a web application as one of many tabs in a web browser. They
then, either within the application window, accidentally hit CTRL W (or its Mac
equivalent), or from the operating system, issue a close application command.
Most apps (as opposed to the more passive browsers) detect that new content
has been developed and in is jeopardy of being lost and therefore prompt the
user to the status of this possible data loss. The browser, unless I'm missing
something, seems to have a different status within the OS and just closes
without ceremony.
The way I've handled this is the past is to have an onunload script associated
with the body: onunload=if (confirm('Save before quitting')) (SaveIt());
where SaveIt is some magic function which writes to disk (I understand that
such a technique will standardize writing to local drive space in HTML5). I
also understand that there will be ways of overriding the default definitions
of CTRL-W etc. so that the developer may change these unpleasantries inherited
from the browser. However, in the case of the solution using onload/confirm,
(if you're not averse to using IE and looking at VML then see
http://srufaculty.sru.edu/david.dailey/grapher/grapher.96.html for an example)
, you have two choices: save and cancel -- cancel terminates without saving,
save terminates after saving.
Has this group or HTMLWG yet decided on a way of preventing accidental loss of
work for web applications in a way similar to how applications handle the
situation?
cheers,
David
Re: [whatwg] The div element
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. -Nicholas 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] snip 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. Regards, Dave
Re: [whatwg] The div element
On Thu, Feb 28, 2008 at 5:07 PM, [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. -Nicholas section adds structure to *content*. div adds structure to the entire document. If you insist, section is the new div for content structure, just like nav is the new div for navigation elements or footer is the new div for footer elements. If used semantically, sections will only appear in the actual content of the page, not on the overall structure. As for being confusing, the name should certainly help sort things out. Am I wrapping up a section of content? section it is! Am I wrapping a header, footer, nav, aside? Already done! Anything else? Use div. I feel you're probably just ignoring the distinction between the content of a page and the page as a whole. The division is pretty clear in most examples in the wild, and so the usage should be fairly clear as well. ~TJ
Re: [whatwg] Proposal for a link attribute to replace a href
Pawe? Stradomski wrote: W li?cie Shannon z dnia czwartek 28 lutego 2008: How should nested links work? Suppose I put href=http://a; on p element and href=http://b; on a span inside that p. What should happen when the user clicks on that span? That's the reason why nested a's are forbidden by HTML 4 and XHTML 1. I'm not against href on every element, but then nesting elements with href attribute should be forbidden. Similarly href should be forbidden on interactive elements (buttons etc.), so making it global would be a problem. Browsers were a lot more primitive back then. I have used nested onclick() handlers in the real world and had no problems, nor did my users. I have also safely used onclick on form elements. The browser always knows which element is directly under the mouse (that's why :hover works). Only the link directly under the mouse should trigger. Again, this is behaviour that onclick and :hover already perform in all major browsers. As I've said before, href should not be forbidden on interactive elements, the spec should define the event hierarchy, eg: event-input-link/href Chris wrote: Tables should be used to present tabular data. Tabular data is something the user may want to meditate or to copy; their content cannot be grasped in a glance. Hyperlinked text should be a concise description of the content of the other page; a table does not meet that requirement. This design violates the least surprise principle. ... It would be difficult to style a hyperlink within a hyperlink; moreover, a hyperlink that contains another hyperlink is not concise, see above. You'll never eliminate bad design by putting these limitations in the spec. What you'll do is make bad designers work around them (using onclick() or atable.../table/a). I've seen it happen before more times than I can count. Bad designers don't validate their code either. On the other hand designers who do know what they are doing can be artificially restricted or forced into non-compliance by these sorts of rules. What makes sense is really a matter of context (or clients), and cannot be discussed in abstract like this. The point is there _are_ situations I have experienced myself where link/href would be a better alternative than a or onclick() and situations where nested interaction is useful and still makes sense to the user. Finally, style should follow the stylesheet rules like everything else, nested or not. There is not a strong case for making the browser distinguish the boundaries between nested links if the designer chooses not to. Geoffrey Sneddon wrote: While yes, you could rely on something like that, it totally breaks in any user agent without scripting support. Nothing else, to my knowledge, in HTML 5 leads to total loss of functionality without JavaScript whatsoever. Well nothing except global/session/database storage, the irrelevant attribute, contenteditable, contextmenu, draggable, the video and audio elements, canvas and the connection interface. Some of these can't even be done in Javascript. Despite the efforts of this group backwards-compatibility is ultimately the authors responsibility. eg: !-- Modern content -- div link=foo.htmlfoo/div !-- Fallback / Search-engine content. Not rendered in HTML5 compliant browser -- a href=foo.html irrelevantfoo/a Nothing else reinvents the wheel for something with which we already have a perfectly fine solution already. If it were perfectly fine designers wouldn't be asking for this. My view is that a and onclick do not solve all cases where hyperlinks are needed. Overall I'd say that most objections to a global href tend to focus on all the bad things a designer could do with it. However I deal with many designers, good and bad, and I can categorical state that the bad ones have no qualms about mangling pages using the Javascript, plugins and non-compliant markup already at their disposal. Everytime you deny them a feature to make them behave you just encourage them to go out and write another hack. Making the language more flexible will not make things any worse. Using bad designers as a reason to deny features is basically an argument for aborting all work on new HTML5 features. I could name 100 ways to abuse the storage proposals yet we persist because they are useful. Global href is useful, and it should be discussed on the basis of correct usage and what its behaviour should be (ie, my first post). Shannon
Re: [whatwg] several messages about serialising HTML and related subjects
Executive summary: I did most of the changes suggested below. On Wed, 15 Aug 2007, Simon Pieters wrote: The spec says: Other nodes types (e.g. Attr) cannot occur as children of elements. If they do, this algorithm must raise an INVALID_STATE_ERR exception. s/elements/elements or documents/ as the algorithm can be used for documents as well. What about PIs? They can occur as children of elements or documents. How? On Wed, 15 Aug 2007, Simon Pieters wrote: The serializing HTML fragments algorithm talks about child node to refer to the current node being processed. This is a bit confusing, and I think current node would be clearer. Done. On Thu, 16 Aug 2007, Lachlan Hunt wrote: There is a possible issue serialising HTML fragments section [1]. The algorithm seems fine for use with things like innerHTML, but there are other issues that should be considered when serialising to a file, database, network stream or something. Such serialisers should consider the character encoding. Although a Unicode encoding should ideally be used, some serialisers may need to serialise to a different encoding at the request of the user or limitations of the environment. In such cases, the serialisation should output appropriate character references for characters that can't be represented. It should also handle outputting the appropriate meta charset= and/or BOM, especially in environments that can't declare it at the transport level like HTTP can. Perhaps the spec should say something about this issue somehwhere. [1] http://www.whatwg.org/specs/web-apps/current-work/#serialising The section is specifically for serialising a subtree to a Unicode stream without mutation, not to a byte stream. What's the use case that isn't covered by 8.1 Writing HTML documents? On Mon, 27 Aug 2007, Simon Pieters wrote: IE7 and Firefox serialize U+00A0 characters in data and attribute values as nbsp; when getting innerHTML. Safari and Opera don't. Should the spec be aligned with IE7 and Firefox here? http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Cscript%3Ewindow.onload%3Dfunction%28%29%7Bw%28document.body.innerHTML%29%7D%3C/script%3E%3Cp%20title%3D%22x%A0x%22%3Ex%A0x I don't see any great benefit to doing so; do any pages require this? On Tue, 28 Aug 2007, Alexey Proskuryakov wrote: This has caused a compatibility issue for WebKit at least once. In that case, we got away with evangelizing, but we still track this as a bug that needs to be fixed eventually. http://bugs.webkit.org/show_bug.cgi?id=11947 Ah. Ok then. Done. On Tue, 28 Aug 2007, Boris Zbarsky wrote: For what it's worth, the relevant Mozilla bugs are https://bugzilla.mozilla.org/show_bug.cgi?id=165686 and https://bugzilla.mozilla.org/show_bug.cgi?id=169590 Cool, thanks. On Tue, 11 Sep 2007, Simon Pieters wrote: Consider the following document: h:p xmlns:h=http://www.w3.org/1999/xhtml;x//h:p When getting innerHTML on the root element, should the serialization declare the no namespace explicitly as in x xmlns=/? (I think it should because setting innerHTML will imply namespace declarations so it might change meaning if you insert it somewhere else with innerHTML.) I've added this: | If any of the elements in the serialisation are in the null namespace, | the default namespace in scope for those elements must be explicitly | declared as the empty string. Is that ok? Also, the spec says: In an XML context, the innerHTML DOM attribute on HTMLElements and HTMLDocuments, on getting, must return a string in the form of an internal general parsed entity [...] ...and then goes on to say that some DocumentType nodes must raise an exception, however internal general parsed entities can't have doctypes in the first place. Oops. Fixed. Only elements should return internal general parsed entities; documents should return document entities. Empty documents now raise an exception. Finally, the spec lists the following as something that throws: A Text node whose data contains characters that are not matched by the XML Char production. [XML] But Text data is not the only case that might not match the Char production in XML. Comment data, CDATASection data, ProcessingInstruction target, and, I think, Attr value. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
