[whatwg] Pre, code and semantics in HTML5: Wishful thinking?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was reading through the HTML5 spec the other day and I noticed this tidbit: To represent a block of computer code, the pre element can be used with a code element; to represent a block of computer output the pre element can be used with a samp element. Similarly, the kbd element can be used within a pre element to indicate text that the user is to enter. The implication is that document authors are recommended to use precode to wrap all of their programming code instead of a lone pre, if they wish to be fully semantic. This feels needlessly verbose and abusive of code, which traditionally has been used to mark single-liners. It also makes it extremely difficult to style pre as a block for code, as the only semantic indication that the contents of the pre block are computer code is its child. You'd end up having to say pre class=codecode if you wanted to style pre as well. At the same time, I still think the semantics of whether or not a pre tag indicates a plaintext file, or a piece of ASCII art, or computer code, is somewhat important. However, I think this information would be more appropriately given as an attribute. Thanks for reading, Edward P.S. Please CC my address on all replies. - -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIXrSQqTO+fYacSNoRAn1WAJ95X7i0Rf4sMGuj4n5qEEWoEH4CuwCfUnP8 TIADRZ6VRXWK2AC9tIATl8E= =TY06 -END PGP SIGNATURE-
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
Michael A. Puls II wrote:
Anyway, the use case for .value is:
...
pFile to attach: p
pinput type=file
onchange=document.getElementsByTagName('p')[0].innerHTML +=
this.value;/p
...
How is that a use case? Please explain why outputting the value of the
control in an adjacent paragraph is useful at all and why authors would
do it. The value is visible in the control itself, so that seems
unnecessary.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Pre, code and semantics in HTML5: Wishful thinking?
Edward Z. Yang writes: ... authors are recommended to use precode to wrap all of their programming code instead of a lone pre, if they wish to be fully semantic. This ... makes it extremely difficult to style pre as a block for code, as the only semantic indication that the contents of the pre block are computer code is its child. You'd end up having to say pre class=codecode if you wanted to style pre as well. Why would you need to -- surely you could just put the styling on the code instead (using pre + code to select only code elements inside pre-s)? Smylers
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
On 6/22/08, Lachlan Hunt [EMAIL PROTECTED] wrote:
Michael A. Puls II wrote:
Anyway, the use case for .value is:
...
pFile to attach: p
pinput type=file
onchange=document.getElementsByTagName('p')[0].innerHTML
+=
this.value;/p
...
How is that a use case? Please explain why outputting the value of the
control in an adjacent paragraph is useful at all and why authors would do
it. The value is visible in the control itself, so that seems unnecessary.
The file is visible in the control itself, but:
If the control is not long enough, you might not see the filename
unless you scroll in the field or the script resizes based on a
multiple of the length of .value. Even then, the path might be
considered noise.
An author might provide the filenames in a more friendly and readable way.
As another example, imagine you have input type=file and onchange,
it adds a filename to a SELECT element and resizes the element.
Then, the select has an onchange listener itself. When you select a
different file in the SELECT, you can make something happen.
For example, you can browse to .wav files and add them to a select
playlist. Then, you can select each of the filenames to have them play
with Audio() for example. Attached is a super basic example of that.
Instead of Audio(), you might load theora videos and play them with
the VideoLan plugin or load wmv files and play them with WMP.
--
Michael
Select a file in the playlist to play it
Add a .wav file to the playlist:
[whatwg] document.readyState and its initial value
document.readyState was added to HTML5 in April of this year. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000652.html http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current Each document has a current document readiness. When a Document object is created, it must have its current document readiness set to the string loading. Various algorithms during page loading affect this value. When the value is set, the user agent must fire a simple event called readystatechanged at the Document object. As far as I can tell via google, there has been no discussion of this property on lists.whatwg.org, so I'd like to suggest a small enhancement to the spec. HTML5 says that the current document readiness should be loading when the document is created; instead the initial state should be uninitialized. document.readyState was initially defined by Microsoft as a proprietary extension to DOM. Here's their MSDN documentation of document.readyState: http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx An object's state is initially set to uninitialized, and then to loading. When data loading is complete, the state of the link object passes through the loaded and interactive states to reach the complete state. I believe HTML5 should change to agree with Microsoft on this point. Safari and Opera have implemented document.readyState to agree with Microsoft and I don't think it's appropriate for HTML5 to break new ground here. This matters to me because I'm trying to fix Firefox to support this property, and we need to know what the initial state should be. The point is small and not very important because it's almost impossible to encounter an HTML document in Internet Explorer in the uninitialized state. But I think the fix is small and uncontroversial: Index: source === --- source (revision 1790) +++ source (working copy) @@ -4613,7 +4613,7 @@ pEach document has a dfncurrent document readiness/dfn. When a codeDocument/code object is created, it must have its spancurrent document readiness/span set to the string - loading. Various algorithms during page loading affect this + uninitialized. Various algorithms during page loading affect this value. When the value is set, the user agent must spanfire a simple event/span called code title=event-readystatechangedreadystatechanged/code at the
Re: [whatwg] document.readyState and its initial value
On Sun, 22 Jun 2008, Dan Fabulich wrote: The point is small and not very important because it's almost impossible to encounter an HTML document in Internet Explorer in the uninitialized state. But I think the fix is small and uncontroversial: Actually the testability is the most important aspect. Could you provide some tests that show when IE switches from uninitialised to loading and so on? At the moment the spec is as close as I could get to what IE actually does. (MSDN is woefully inaccurate when it comes to these things, so I wouldn't pay too much attention to it.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] document.readyState and its initial value
Ian Hickson wrote: On Sun, 22 Jun 2008, Dan Fabulich wrote: The point is small and not very important because it's almost impossible to encounter an HTML document in Internet Explorer in the uninitialized state. But I think the fix is small and uncontroversial: Actually the testability is the most important aspect. Could you provide some tests that show when IE switches from uninitialised to loading and so on? At the moment the spec is as close as I could get to what IE actually does. (MSDN is woefully inaccurate when it comes to these things, so I wouldn't pay too much attention to it.) As far as I know I can't exhibit a test demonstrating IE switching from uninitialized to loading. The document is normally in the loading state before you get your hands on it. If testability is the top priority then the spec probably shouldn't change. There is a way to get a document in the uninitialized state using document.createDocumentFragment(). IE erroneously creates a document in that case instead of a document fragment; the document has readyState uninitialized. However, there is no way to take that document and get it into a loading state as far as I know (obvious methods like .open() just throw errors instead). Furthermore, MSDN *does* claim that the states through which an object passes are determined by that object; an object can skip certain states (for example, interactive) if the state does not apply to that object. So, the current state of the spec is certainly defensible. However, I note that it would be legal under the terms of the MSDN specification if some future version of IE *did* expose a way to make an uninitialized document on which you could later call .open(), and the HTML5 spec as-is would make that illegal. It's tempting to say that the readyState can start with either uninitialized or loading; certainly it's odd that we'd just hike it up to loading because our test mechanisms are usually too coarse-grained to detect a readyState in its uninitialized state. But, oddity is par for the course in DOM, so I guess we'll just follow the HTML 5 spec as-is, initialize readyState to loading in the object constructor, and keep our fingers crossed. -Dan
