[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
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] 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
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
