Re: [whatwg] set input.value when input element has composition string
Hi, Kang-Hao.
On 2011/02/28 21:31, Kang-Hao (Kenny) Lu wrote:
Hello Makoto,
(Cc+ public-webapps)
(11/02/25 15:16), Makoto Kato wrote:
Hi,
This is simple sample. This behavior is different on all web browsers
when input element has composition/preedit string for IME.
A relevant question here, I think, is where the cursor should go when
the value of the text box is set by script. For Safari5, it always goes
to the end when the value is set. For FF4.0b11, the cursor stays in
previous position when the value to be set is the same and goes to the
end when the value is different. Is this a known incompatibility? I find
the behavior of FF quite strange.
On Safari 5, even if textbox has IME composition string, text into
textbox can be replaced by DOM/script. But other browser's behaviors
are different, and this is no specification when textbox has composition
string. Although IE, Chrome and Opera keep composition string after
value is replaced by DOM, each behavior is different.
This is the result for this test on each browsers. When textbox has IME
composition string such as ABCDEFG, then script (textbox.value = 123;)
is called, textbox becomes...
1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G).
2. 123 (composition string is removed).
3. ABCDEFG (ABCDEFG keeps composition state and caret is after G).
Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is Chrome
10 and IE9.
Also, on Firefox/Gecko, since there is some bugs, key input cannot work
until IME is turned off. So to fix this, I am talking with Ehsan about
right specification. But there is no discussion about this
specification/behavior at WHATWG.
If input element has composition string by IME, should it cancel
composition string and set value by script? Or should it cancel
setting value since it has composition string?
What makes sense to me is:
1. the cursor always goes to the end
2. the composition string goes with the cursor, which should not change.
But I am not sure whether this is the right way to go.
Cheers,
Kenny
script
function setvalue() {
document.getElementById('test').value = replaced;
}
/script
body onload=setTimeout('setvalue()',5000)
input type=text id=test/
/body
-- Makoto Kato
-- Makoto Kato
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] 7.3 Timers
On Feb 28, 2011, at 8:19 PM, Boris Zbarsky wrote: But well, the signature looks like there is only one parameter No. If there were only one parameter, the signature would say |in any args|. It actually says |in any... args| which means any number of arguments. See http://www.w3.org/TR/WebIDL/#dfn-variadic-operation Thanks for highlighting that, I see it more clearly By the way I still don't see it in the process, I only see: - the get the timed task handle step - and the get the timeout step But couldn't setTimeout() accept natively a Date object in place of the timeout parameter Note that if you set a timeout for 1 hour from now, and then the computer goes to sleep for 3 hours, then the timeout will fire 1 hour after the computer wakes up, not immediately on wakeup. I agree this is a problem for the listed use cases This is another good reason: - to use a different method name for this purpose - to provide a better solution to these needs I'm not sure which one could be either correct and intuitive - scheduleTask() ? - setTaskDate() ? - setCron() ? anything else ? The question would be, if the computer goes to sleep, should the user agent : 1 - wake up the computer to execute the function ? 2 - wait until it wake up to execute it ? 3 - ignore the handler if its to late ? The choice between options 2 and 3, could be settable as part of the method signature. The first option looks more sensible and in my opinion should require to activate a setting or ask the user to accept for the current domain This show up another requirement As for a Web Application, User Agents may provide a setting dialog so it could ask to the user to accept a list of option for the application This way, the user won't miss line on top of the page asking authorizations for each ones Example: setDomainSettings( message, required, optional); where required and optional parameters would expect a list of options to activate including: - geolocation - storage with specific size - crons - allow popup - remember password Thoughts ? Alexandre.
Re: [whatwg] Idea for having InputXML Or ClickXML for HTML5+
On 3/1/11, Narendra Sisodiya naren...@narendrasisodiya.com wrote: We can record mouse and keyboard activity in xml. There are many events which are resolution independent. for example mouse clicks, button press events . Now suppose you are dealing with some animation or game or just a slideshow. what you do ? you type some buttons from mouse or keyboard. Now if you can record the timeline of these events then we can play back at anytime. IMO, you should record when users advance slides (rather than when users press spacebar, activate their cursor on a specified region, flick their accelometer wand, or wipe their touch touchpad in a given direction).
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. As to comment 2, I agree that the various traps put in place are exceptionally annoying. An alternative would be a forced closing via the browser rather than some modification of the behavior of Javascript. That would side step the question of Have you covered all of the annoying cases (onbeforeunload, on unload, on hide...)?. On 2011-02-28 19:42, Ian Hickson wrote: On Thu, 25 Nov 2010, Biju wrote: 1. Can we deprecate alert(), confirm(), prompt() ? At present many web2.0 js libs are providing alternate [and cool looking] methods to achieve use cases where we need to use alert(), confirm(), prompt(). So do we need those modal dialogs any longer? Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. 3. also if we are keeping them, can we add an optional parameter for a timeout milliseconds to self dismiss the modal prompt. What's the use case? On Thu, 25 Nov 2010, Biju wrote: In a software application there is no need to have prompt to the user if the application is not planning to do any branching after user response. When we have alert(), it dont give user any choice other than pressing OK Hence it not possible to code any branching statement after result of user action. (with exception Press OK after you insert DVD to the drive ) So only use for alert() I see is not make a delay, that use case can be improved if web programmer can provide a default time out. As you point out in your original e-mail, it seems like this kind of use case is better handled by Web 2.0 JavaScript libraries. In the medium term I expect we will introduce a feature to create modal and non-modal in-page dialogs using markup, so this will likely become moot. On Thu, 25 Nov 2010, Markus Ernst wrote: Maybe, instead of your original suggestion, it might be worth thinking about making alert()/confirm()/prompt() dialogs styleable via CSS? Then those fancy JS lib dialogs would get obsolete, and we had the favour of both nice look and support for the special purposes of those dialogs. This would be a side-effect of the aforementioned markup-based dialogs. On Thu, 25 Nov 2010, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. On Thu, 25 Nov 2010, Nikita Popov wrote: That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. On Thu, 25 Nov 2010, Markus Ernst wrote: Opera even provided a Stop executing scripts checkbox in the alert() dialog for years already, which made it my preferred browser for debugging my scripts (handy if you have forgotten an i++ in a loop, and placed an alert() inside). Indeed. On Thu, 25 Nov 2010, Benjamin Poulain wrote: The specification deprecates some elements that use to be widely used (the elements font, big, center, etc). Actually it obsoletes them. Deprecating is only a recommendation for authors to not use the feature. It's hard to effectively do that with script since there's no good way to do scripting validation.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
2011-03-01 11:13 EEST: Robert O'Callahan: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. We already have onbeforeunload that almost does the trick... How about adding a new property for this that needs to be set before user tries to unload the page in the first place. For example: window.onbeforeunloadmessage defaults to an empty string and if this property is set to non-empty string, then the UA should prompt this message with buttons Close anyway and Stay on page (or equivalent) before unloading the document. This allows for following fixes to current unload and onbeforeunload features: - Page script must set this message at the moment the page should not be closed without consideration - UA may display visual clue that a tab should not be closed even before the closing is tried - UA does not need to run any JS code before closing a tab because this is only a string that is either empty or not - UA may disable/stop running JS the moment the user tries to close the tab and continue running JS only if user hits the Stay on page button. What do you think? -- Mikko
Re: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt).
On 28 Feb 2011, at 17:52, Bjartur Thorlacius wrote: Can't we extend the existing window.status? It's supported by some older UAs (and ignored by others, because of confusing UI), but if the UI distinguishes page messages from browser and system messages, it's usable (aside from a historical API, but if browsers ignore setting the window.status to the empty string). The window.status property [1] doesn't seem to be in the WHATWG HTML spec, I could only find the window.statusbar.visible property [2]. But I doubt that any mobile UAs have a status bar, and it's also hidden by default on Mac OS X Safari (and possibly other desktop UAs as well). However, some mobile platforms have a local notification service [3] [4] [5] [6]. A new window.notify() function might be useful, so that a background card/tab/window can display a message to the user. (Unfortunately, iOS currently uses a modal dialog for its UILocalNotification service. A better implementation might be to put a Notification Center icon in the multitasking UI, similar to the Print Center [7] used by AirPrint.) [1] https://developer.mozilla.org/en/DOM/window.status [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browser-interface-elements [3] http://blog.cocoia.com/2011/notify/ [4] http://developer.android.com/guide/topics/ui/notifiers/notifications.html [5] http://developer.apple.com/library/ios/#documentation/iPhone/Reference/UILocalNotification_Class/ [6] http://developer.palm.com/index.php?option=com_contentview=articleid=1677Itemid=51 [7] Figure 6-4 and Figure 6-5 http://developer.apple.com/library/ios/#documentation/2DDrawing/Conceptual/DrawingPrintingiOS/Printing/Printing.html
Re: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt).
On 03/01/2011 04:50 PM, Ben Rimmington wrote: However, some mobile platforms have a local notification service [3] [4] [5] [6]. A new window.notify() function might be useful, so that a background card/tab/window can display a message to the user. See [1] for the current state-of-play in giving access to system notification mechanisms. [1] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html
Re: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt).
On 3/1/11, Ben Rimmington benrimming...@me.com wrote: On 28 Feb 2011, at 17:52, Bjartur Thorlacius wrote: Can't we extend the existing window.status? It's supported by some older UAs (and ignored by others, because of confusing UI), but if the UI distinguishes page messages from browser and system messages, it's usable (aside from a historical API, but if browsers ignore setting the window.status to the empty string). The window.status property [1] doesn't seem to be in the WHATWG HTML spec, I could only find the window.statusbar.visible property [2]. But I doubt that any mobile UAs have a status bar, and it's also hidden by default on Mac OS X Safari (and possibly other desktop UAs as well). However, some mobile platforms have a local notification service [3] [4] [5] [6]. A new window.notify() function might be useful, so that a background card/tab/window can display a message to the user. (Unfortunately, iOS currently uses a modal dialog for its UILocalNotification service. A better implementation might be to put a Notification Center icon in the multitasking UI, similar to the Print Center [7] used by AirPrint.) I meant to suggest displaying strings assigned to (the unstardandized property) window.status, supported by some browsers, using e.g. methods described in your post.
Re: [whatwg] Optional non-blocking mode for simple dialogs (alert, confirm, prompt).
On 1 Mar 2011, at 15:58, James Graham wrote: On 03/01/2011 04:50 PM, Ben Rimmington wrote: However, some mobile platforms have a local notification service [3] [4] [5] [6]. A new window.notify() function might be useful, so that a background card/tab/window can display a message to the user. See [1] for the current state-of-play in giving access to system notification mechanisms. [1] http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html Thanks for the link. The Web Notifications spec doesn't mention a mailing list -- I assume that public-weba...@w3.org should be used. P.S. I've just found a good summary of mobile Web technologies: http://www.w3.org/2011/02/mobile-web-app-state.html
Re: [whatwg] wrapper element
[resending reply, sorry again with problems]
My idea of wrapper or content was to identify actual content from the rest
of the window space. Like headerwrapperactual content centered at
960px/wrapper/header
Thanks, I hope i can still contribute to the list, even if my thoughts seem
odd.
2011/2/28 Ashley Sheridan a...@ashleysheridan.co.uk
On Mon, 2011-02-28 at 18:46 +, usuario wrote:
[Had problems sending my mails to the list, resending message]
Some of you may be questioning why a wrapper element if it has not
semantics, the thing is, It DO have semantics.
Wrapper:
a container element whose solely purpose is to isolate flow content for
visually appealing purposes. It it usually used for applying margin, padding
to inner elements, and dimensionally separating them from its real parent.
*example, consider:*
header
div class=wrapper
h1Header 1/h1
pthis content is centered because margin: 0 auto is applied to
parent of div.wraper element/p
I have always worked, I'm almost standard, sometimes people don't
call me wraper but 'container' or 'content' instead
/div
/header
*Against:*
header
wrapper
h1Header 1/h1
pthis content is centered because margin: 0 auto is applied to
parent of wrapper element/p
I think I'm more semantic because I'm specifically designed for this
task, and I do it very well. What do you think?
/wrapper
/header
Moreover.
Why not borrow the g from SVG (meaning to group together -- the
semantics may be a bit more accessible in some cross-linguistic sense than
wrap, particularly because of the silent w in wrap which throws a lot
of folks for a loop)?
Don't know if that's the solution, i just don't discard it.
div carries no semantic meaning. * If you are using it for such, the
semantic is purely internal to your application*, and thus doesn't
carry the common meaning of semantics as used on the web.
We have no problems with div definition. But i think you are not right in
your statement.
Answer this, Are wrappers purely internal to my(of mine) application? that's
a capitalized lie, just think on it. Most applications use a wrapper-like
div. You had, and i don't know you.
We have to start deciding what do we want from html5, at what degree do we
want a more semantic web? why just header, why just footer.
I can assure you the world was fine with div id=header, but so, why
header was created for? It was created because being so widely used,
somebody believed it was *more semantic* to convert it into an element.
div is the wrapper element. That's its entire purpose for living. ^_^
div was not creating for wrapping things, but for contain them. When you
wrap something, you are giving it a different implicit meaning to that
wrapper div.
By it's very nature a div tag is a wrapper already. Your above code could
be written as:
header
div
h1Header 1/h1
pthis content is centered because margin: 0 auto is applied to
parent of div.wraper element/p
I have always worked, I'm almost standard, sometimes people don't
call me wraper but 'container' or 'content' instead
/div
/header
And the CSS used to reference the elements would be
header div{/* css here */}
header div h1{/* css here */}
header div p{/* css here */}
Your proposed wrapper serves no semantic purpose other than grouping the H1
and p tags together, but if they are the only siblings of any element that
is already happening, there's no need to call the element a wrapper, it is
one anyway.
I don't understand the difference in your context of wrapper and container,
but it seems to me one is a synonym for the other.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
[whatwg] Ongoing work on an editing commands (execCommand()) specification
Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking, particularly from implementers but also from anyone else familiar with the APIs (e.g., someone who's used them in practice): http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD The plan is that this should be merged into the main HTML spec, with a full test suite, by the end of August. Feedback appreciated.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 1:13 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Please see my identical question and Tab's answer, which Ojan's reply quoted. PK
[whatwg] Giving the body tag a new meaning.
According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. We may think in giving it a more explicit meaning, and freeing it for semantic availability (just an example): !DOCTYPE html html head !--metadata, system, config -- meta/meta script/script link/link /head markup !-- window, render, main, app, structure -- header h1/h1 p/p /header body p/p p/p /body footer p/p /footer /markup /html
Re: [whatwg] 7.3 Timers
On 3/1/11 4:37 AM, Alexandre Morgaut wrote: No. If there were only one parameter, the signature would say |in any args|. It actually says |in any... args| which means any number of arguments. See http://www.w3.org/TR/WebIDL/#dfn-variadic-operation Thanks for highlighting that, I see it more clearly By the way I still don't see it in the process, I only see: - the get the timed task handle step - and the get the timeout step See http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout step 3. Get the timed task is defined at http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#get-the-timed-task and step 1 of that describes what you're interested in. -Boris
Re: [whatwg] Giving the body tag a new meaning.
On Tue, Mar 1, 2011 at 10:54 AM, usuario soyh...@gmail.com wrote: According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. We may think in giving it a more explicit meaning, and freeing it for semantic availability (just an example): !DOCTYPE html html head !--metadata, system, config -- meta/meta script/script link/link /head markup !-- window, render, main, app, structure -- header h1/h1 p/p /header body p/p p/p /body footer p/p /footer /markup /html I don't understand what problem you're trying to solve, nor what your proposal is. Are you proposing to rename body? If so, there are significant legacy constraints preventing that (namely, a lot of code depends on a missing body tag being inferred). ~TJ
Re: [whatwg] Giving the body tag a new meaning.
The real issue is with change, never is too late. Many of the new elements in html5 are for semantic purposes. Being now a header and a footer, there is only one left thing that's pretty obvious. I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. 2011/3/1 Tab Atkins Jr. jackalm...@gmail.com On Tue, Mar 1, 2011 at 10:54 AM, usuario soyh...@gmail.com wrote: According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. We may think in giving it a more explicit meaning, and freeing it for semantic availability (just an example): !DOCTYPE html html head !--metadata, system, config -- meta/meta script/script link/link /head markup !-- window, render, main, app, structure -- header h1/h1 p/p /header body p/p p/p /body footer p/p /footer /markup /html I don't understand what problem you're trying to solve, nor what your proposal is. Are you proposing to rename body? If so, there are significant legacy constraints preventing that (namely, a lot of code depends on a missing body tag being inferred). ~TJ
Re: [whatwg] Giving the body tag a new meaning.
On 03/01/2011 09:09 PM, ext usuario wrote: I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. That is a bit weak. You should present solid use cases, especially for big changes... cheers, Benjamin
Re: [whatwg] Giving the body tag a new meaning.
On 3/1/11 1:54 PM, usuario wrote: According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. Why not propose a better definition then?
Re: [whatwg] Giving the body tag a new meaning.
Why not propose a better definition then? Because than wouldn't likely solve the semantic issue (if we can call it an issue). I am not an html expert, it is even hard to me figure even what i propose. If a tell it, is because belive on it. But if you like the idea, i can try make it more solid. 2011/3/1 Mike Taylor michaelaarontay...@gmail.com On 3/1/11 1:54 PM, usuario wrote: According to the spec: The body element represents the body of a document (as opposed to the document’s metadata). I think definition is a bit ambiguous. Why not propose a better definition then?
Re: [whatwg] Giving the body tag a new meaning.
On Tue, Mar 1, 2011 at 12:09 PM, usuario soyh...@gmail.com wrote: The real issue is with change, never is too late. Many of the new elements in html5 are for semantic purposes. Being now a header and a footer, there is only one left thing that's pretty obvious. I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. So, what is the problem you're trying to solve? Semantics are useless on their own; we only care about semantics insofar as they help us to solve problems. For example, the new sectioning elements help somewhat in styling and code readability, and make the page easier to automatically navigate, so things like screen-readers can consume the pages more easily. What problem is caused by the current body tag that you'd like to fix? It may be helpful to read http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F, which explains the process by which we add new features to HTML. ~TJ
Re: [whatwg] wrapper element
On 3/1/11, usuario soyh...@gmail.com wrote: [resending reply, sorry again with problems] My idea of wrapper or content was to identify actual content from the rest of the window space. Like headerwrapperactual content centered at 960px/wrapper/header That seems like a presentational problem, better solved by fixing the CSS box model or a related technology. It'd be hard to see where to put wrapper elements without knowing the ultimate rendering of the document, causing either a lack of wrappers somewhere, or wrappers being injected everywhere. If you need compatibility, consider using JavaScript element injection. Thanks, I hope i can still contribute to the list, even if my thoughts seem odd. Straight from my mind, and the reason I'm here.
Re: [whatwg] Giving the body tag a new meaning.
On 3/1/11, usuario soyh...@gmail.com wrote: Why not propose a better definition then? Because than wouldn't likely solve the semantic issue (if we can call it an issue). I am not an html expert, it is even hard to me figure even what i propose. If a tell it, is because belive on it. But if you like the idea, i can try make it more solid. Thing is, that body is automatically opened for text nodes that the parser doesn't recognize as being in head (either per DTD or hard coded element names) and, IIRC, for any nodes after head ends. Putting text after /head and before body will thusly result in said text being parsed as in body and the body tag getting ignored, as bodys can't be nested. As a result, everything must be in either head or body, and potentially after the body. It might be feasible to add additional elements after the body, if their content belongs neither with head's metadata nor body's linear main content.
Re: [whatwg] Giving the body tag a new meaning.
On Tue, 2011-03-01 at 12:32 -0800, Tab Atkins Jr. wrote: On Tue, Mar 1, 2011 at 12:09 PM, usuario soyh...@gmail.com wrote: The real issue is with change, never is too late. Many of the new elements in html5 are for semantic purposes. Being now a header and a footer, there is only one left thing that's pretty obvious. I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. So, what is the problem you're trying to solve? Semantics are useless on their own; we only care about semantics insofar as they help us to solve problems. For example, the new sectioning elements help somewhat in styling and code readability, and make the page easier to automatically navigate, so things like screen-readers can consume the pages more easily. What problem is caused by the current body tag that you'd like to fix? It may be helpful to read http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F, which explains the process by which we add new features to HTML. ~TJ I agree. Usuario, in the example you've given the newly proposed version of the body tag only encloses content that isn't otherwise encompassed by the header or footer, meaning it serves no purpose to distinguish it from the header and footer because those specific tags are already doing that. The body tag holds all the content that is presented to the user. After a long look at a wide variety of websites, the header and footer (among other) tags were added to mark those areas of a website out against the actual content. This basically means that anything that isn't a header or a footer is main content. Of course there are things like article and section to further break things down. Think about it a bit like a word-processed document for a moment. In that, all content is deemed to be main content apart from page headers and footers which can be added in. Within the content you can mark up various text as a header or otherwise. A web page isn't too dissimilar, although it allows for far more semantic meaning to be given to content. What you must remember is that the new HTML5 tags aren't just for easier styling but to allow better parsing by non-humans, be it a search engine, screen reader or some content archiver. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Giving the body tag a new meaning.
Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). In HTML, as you say, everything by default is body (about the same a a word document). But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. 2011/3/1 Ashley Sheridan a...@ashleysheridan.co.uk On Tue, 2011-03-01 at 12:32 -0800, Tab Atkins Jr. wrote: On Tue, Mar 1, 2011 at 12:09 PM, usuario soyh...@gmail.com wrote: The real issue is with change, never is too late. Many of the new elements in html5 are for semantic purposes. Being now a header and a footer, there is only one left thing that's pretty obvious. I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. So, what is the problem you're trying to solve? Semantics are useless on their own; we only care about semantics insofar as they help us to solve problems. For example, the new sectioning elements help somewhat in styling and code readability, and make the page easier to automatically navigate, so things like screen-readers can consume the pages more easily. What problem is caused by the current body tag that you'd like to fix? It may be helpful to read http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F, which explains the process by which we add new features to HTML. ~TJ I agree. Usuario, in the example you've given the newly proposed version of the body tag only encloses content that isn't otherwise encompassed by the header or footer, meaning it serves no purpose to distinguish it from the header and footer because those specific tags are already doing that. The body tag holds all the content that is presented to the user. After a long look at a wide variety of websites, the header and footer (among other) tags were added to mark those areas of a website out against the actual content. This basically means that anything that isn't a header or a footer is main content. Of course there are things like article and section to further break things down. Think about it a bit like a word-processed document for a moment. In that, all content is deemed to be main content apart from page headers and footers which can be added in. Within the content you can mark up various text as a header or otherwise. A web page isn't too dissimilar, although it allows for far more semantic meaning to be given to content. What you must remember is that the new HTML5 tags aren't just for easier styling but to allow better parsing by non-humans, be it a search engine, screen reader or some content archiver. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] banner as a dedicated tag
On Wed, 2011-02-23 at 11:12 -0800, Tab Atkins Jr. wrote: I have untrusted markup from a third party which I would like to safely insert into my page, knowing that the rest of my page is safe from whatever the untrusted markup is doing. Also, the untrusted markup may be doing expensive things, particularly on load, so I'd like to wait until after the rest of the page is loaded before loading the markup. Is this accurate? Correct me if not, but I'll assume it is for now. In many cases the code itself is considered trustworthy, but the ad server's performance suspect. In that case, asynchronous execution of the script is desired. Unfortunately, as the original email points out, the use of document.write() prevents this. Especially for ads, there are considerable advantages to using iframes; however, fully-privileged scripts have advantages too. Despite a decade of warning/ridiculing authors, document.write()'s continued prevalence seems to be evidence of the fact that it is the only mechanism to address a common problem: Where in the document should a script place the content it generates? A patch to Gecko [1] , originally discussed on the list last August [2], seems to address this.It adds a `currentScript` property which references (surprise) the currently executing script. When a script can reliably find itself, authors can use the current semantics of put this script wherever you want the widget to go, asynchronously if they so choose. The proposal seems to have been stalled by the specifics of some additional compilation events that were also included. Beyond the Gecko patch, I'm not sure where adoption stands. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=587931 [2] http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23015.html Will
Re: [whatwg] wrapper element
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.: I believe you're arguing that the wrapper semantic, being similarly ubiquitous, thus needs its own new element as well. What you're missing is that the wrapper semantic is precisely whatdiv already expresses. I do understand usuario's wrapper proposal slightly different from div: Section 4.5.13 of the spec generally states that the div element is conveying structure, but not semantics. Usuario's wrapper is not structural, but purely presentational. It should actually not be there at all from an HTML point of view, but is necessary for CSS reasons. I agree with Bjartur Thorlacius' point that it makes more sense to enhance CSS the way that presentational markup gets totally obsolete in the future - but the idea of an element that is explicitly non-structural does not look that odd to me.
Re: [whatwg] Giving the body tag a new meaning.
On Tue, 2011-03-01 at 21:59 +, usuario wrote: Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). In HTML, as you say, everything by default is body (about the same a a word document). In a word-processed document the header and footer are separate from the main content (what you keep erroneously calling the body), but are still part of the document content as a whole But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? We are, by creating the header and footer. It's a bit like the way you style alternate table rows; you set the default style for the table and give a class only to the odd rows. The even ones just inherit the default, no need to explicitly give the even ones a class too. By not being part of the header or footer, the rest of the web page content is the regular main content of the page. Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content As explained, for legacy reasons body is what you're calling content there. I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. 2011/3/1 Ashley Sheridan a...@ashleysheridan.co.uk On Tue, 2011-03-01 at 12:32 -0800, Tab Atkins Jr. wrote: On Tue, Mar 1, 2011 at 12:09 PM, usuario soyh...@gmail.com wrote: The real issue is with change, never is too late. Many of the new elements in html5 are for semantic purposes. Being now a header and a footer, there is only one left thing that's pretty obvious. I am not proposing the body tag for disappear, but allow it for a new implementation. And perhaps in say 10 years, discontinue it as document start element, when the change be widely spread. The reason? a better semantics advantages. So, what is the problem you're trying to solve? Semantics are useless on their own; we only care about semantics insofar as they help us to solve problems. For example, the new sectioning elements help somewhat in styling and code readability, and make the page easier to automatically navigate, so things like screen-readers can consume the pages more easily. What problem is caused by the current body tag that you'd like to fix? It may be helpful to read http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F, which explains the process by which we add new features to HTML. ~TJ I agree. Usuario, in the example you've given the newly proposed version of the body tag only encloses content that isn't otherwise encompassed by the header or footer, meaning it serves no purpose to distinguish it from the header and footer because those specific tags are already doing that. The body tag holds all the content that is presented to the user. After a long look at a wide variety of websites, the header and footer (among other) tags were added to mark those areas of a website out against the actual content. This basically means that anything that isn't a header or a footer is main content. Of course there are things like article and section to further break things down. Think about it a bit like a word-processed document for a moment. In that, all content is deemed to be main content apart from page headers and footers which can be added in. Within the content you can mark up various text as a header or otherwise. A web page isn't too dissimilar, although it allows for far more semantic meaning to be given to content. What you must remember is that the new HTML5 tags aren't just for easier styling but to allow better parsing by non-humans, be it a search engine, screen reader or some content archiver. -- Thanks, Ash http://www.ashleysheridan.co.uk -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Reserving XRI and URN in registerProtocolHandler
On Fri, 26 Nov 2010, Brett Zamir wrote: I'd like to propose reserving two protocols for use with navigator.registerProtocolHandler: urn and xri (or possibly xriNN where NN is a version number). See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info on XRI (basically allows the equivalents of URN but with a user-defined namespace and without needing ICANN/IANA approval). Although it was rejected earlier, I don't see that there is any other way for sites to create their own categorization or other behavior mechanisms in a way which is well-namespaced, does not rely on waiting for official approval, and has the benefits of working with the HTML5 specification as already designed. URN is something which I think also deserves to be reserved, if not all IANA protocols. As I see it, the only way for a site to innovate safely in avoiding conflicts for non-IANA protocols is to use XRI (assuming especially if it can be officially reserved). And all of this would be enhanced, in my view, if my earlier proposal for defaultURIs and alternateURIs attributes on a/ could be accepted as well: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20066.html in that it makes it much more likely that people would actually use any of these protocols. On Fri, 26 Nov 2010, Brett Zamir wrote: My apologies, I realized that there might be a modification needed to the HTML5 design of registerProtocolHandler, in that URN and XRI are better designed to work, in many cases, with registration to a specific namespace. For example, one application might only wish to handle urn:earthquakes or xri:http://example.com/myProtocols/someProtocol which hopefully registerProtocolHandler could be expanded to allow such specification without interfering with other URN/XRI protocol handlers which attempted to handle a different namespace. On Fri, 26 Nov 2010, Brett Zamir wrote: I just mean that authors should not use already registered protocols except as intended, thinking that they can use any which protocol name they like (e.g., the Urn Manufacturers Company using urn for its categorization scheme). The definition of the protocol/scheme is what makes it non-conforming to do something else with that protocol/scheme, there's not really anything additional to do here as far as I can tell. On Sat, 27 Nov 2010, Brett Zamir wrote: The only optimal way I can really see this is if there were say a fourth argument added to registerProtocolHandler which allowed (or in the case of URNs or what I'll call XRN for now, required) specifying a namespace (perhaps also allowing URN subnamespace specificity via colons, e.g., ietf:rfc). Let's see if this gets any traction in the first place. If it does, then it might make sense to add new features. Of course, an alternative would be to just register the top-level schemes for the features you want (like isbn:), instead of putting them inside a urn: bucket. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Attitude and Direction of the WHATWG
On Mon, 29 Nov 2010, Charles Pritchard wrote, in part (as, in the interests of making progress, I have not cited or responded to sections of the e-mail that did not include actionable feedback): On 11/27/2010 2:50 AM, Ian Hickson wrote: On Fri, 26 Nov 2010, Charles Pritchard wrote: I want to suggestion a reason for this impasse: the WHATWG intends to produce a scene-graph specification. Other activities are out of scope. I'm not sure what you really mean by scene-graph specification, so it's hard to comment on that specifically. Historically, and still today, the HTML language and its associated APIs are generally intended to primarily convey semantics (meaning, as opposed to presentation) so that they can be rendered in a media-independent way on any device. The HTML language has become even more semantic, less presentational, as CSS+SVG profiles are enhanced. These three sections of the HTML5 specs seem out of scope: Loading Webpages, Web application APIs and Communication I must admit surprise to the idea that loading webpages is not in scope of the spec that defines the format used for web pages. :-) The HTML spec is primarily an API spec, describing how a DOM tree can be manipulated from script and how it must react to user interaction. So the APIs seem entirely in scope. Unfortunately, contenteditable is less accessible to users than it should be. I'd like to see that addressed. Could you elaborate on how it is less accessible than it should be? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Giving the body tag a new meaning.
On 3/1/11, usuario soyh...@gmail.com wrote: Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). I neither write nor speak English natively, but I believe that the body element has to be preserved all but as it is, if only for compatibility. Instead, you should propose putting the main content inside another element inside the body element, say content. Alternatively, you could try using article, but article has further semantics, and is thus unsuitable for wrapping the main content of an index (that is an index). IMO, HTML isn't a good format for indexes, but that's probably only IMO. In HTML, as you say, everything by default is body (about the same a a word document). But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. As previously stated, we can't change the semantics an content model of body. OTOH, it may be possible to put information that may be presented as a footer in head. Head poses strict constraints on both descendant nodes and position in the document (it must come first). It may thus be more suitable to specify a new element positioned _after_ /body containing information that belongs neither to head nor body. This would probably replace aside, which IMO has no place in body which is intended to be loosely linear. Also, I think that most information that's rendered in a footer should be marked up in the head, or as more general metadata fields such as RFC 2822 headers or file xattrs. Headers seem to consist mostly of navigational links, more appropriately marked up with links.
Re: [whatwg] wrapper element
On Tue, Mar 1, 2011 at 2:03 PM, Markus Ernst derer...@gmx.ch wrote:
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.:
I believe you're arguing that the wrapper semantic, being similarly
ubiquitous, thus needs its own new element as well. What you're
missing is that the wrapper semantic is precisely whatdiv already
expresses.
I do understand usuario's wrapper proposal slightly different from div:
Section 4.5.13 of the spec generally states that the div element is
conveying structure, but not semantics.
Usuario's wrapper is not structural, but purely presentational. It should
actually not be there at all from an HTML point of view, but is necessary
for CSS reasons.
Isn't that what the section::outside{ ... } is for? Presentational pseudo
elements in CSS?
http://www.w3.org/TR/css3-content/#wrapping
Granted it's not available as far as I know... but it seems like it meets
usario's needs.
- Jordan
I agree with Bjartur Thorlacius' point that it makes more sense to enhance
CSS the way that presentational markup gets totally obsolete in the future -
but the idea of an element that is explicitly non-structural does not look
that odd to me.
--
Jordan Dobson • Designer / Developer • 425-444-8014 •
About.Me/JordanDobsonhttp://about.me/jordandobson
Re: [whatwg] wrapper element
Am 01.03.2011 23:50 schrieb Jordan Dobson:
On Tue, Mar 1, 2011 at 2:03 PM, Markus Ernstderer...@gmx.ch wrote:
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.:
I believe you're arguing that the wrapper semantic, being similarly
ubiquitous, thus needs its own new element as well. What you're
missing is that the wrapper semantic is precisely whatdiv already
expresses.
I do understand usuario'swrapper proposal slightly different fromdiv:
Section 4.5.13 of the spec generally states that thediv element is
conveying structure, but not semantics.
Usuario'swrapper is not structural, but purely presentational. It should
actually not be there at all from an HTML point of view, but is necessary
for CSS reasons.
Isn't that what the section::outside{ ... } is for? Presentational pseudo
elements in CSS?
http://www.w3.org/TR/css3-content/#wrapping
Granted it's not available as far as I know... but it seems like it meets
usario's needs.
::outside covers only a part of the use cases for wrapping elements -
wrapper containing more than one child elements cannot be replaced by
::outside - consider the very common case of a centered page:
body
div id=container
header/header
nav/nav
div id=contents/div
footer/footer
/div
/body
#container { margin:0 auto; width:50em; position:relative }
#contents { margin-left:10em }
nav{ position:absolute; top:50px; left:0; width:9em }
This case would require some kind of body::inside pseudo element, which
I cannot find in the CSS3 Generated and Replaced Content Module spec
right now. (Well, sorry if I get too much off-topic now.)
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Wed, 1 Dec 2010, Anne van Kesteren wrote: On Wed, 01 Dec 2010 00:27:23 +0100, Ian Hickson i...@hixie.ch wrote: An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo= for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. If we do .vendorFoo shouldn't we just do vendor-foo=? opera, moz, webkit, ms are unique enough and HTML attributes generally do not use hyphens anyway. (And yes, there will be some more vendors, etc. But over the years there have not been many extensions at all so this is all rather manageable.) I think we want a prefix, in general. The problem is that it is not aesthetically pleasing to have a prefix for IDL attributes, unlike content attributes where it doesn't look anywhere near as bad. Hence where we are now, which seems fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Giving the body tag a new meaning.
I neither write nor speak English natively, but I believe that the body element has to be preserved all but as it is, if only for compatibility. Instead, you should propose putting the main content inside another element inside the body element, say content. I agree, body must remain for compatibility, perhaps also able a new tag for its task, and deprecate its current meaning in future versions. content may be a good option as a header and footer sibling. And say not required, but if implemented, do it the right way. 2011/3/1 Bjartur Thorlacius svartma...@gmail.com On 3/1/11, usuario soyh...@gmail.com wrote: Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). I neither write nor speak English natively, but I believe that the body element has to be preserved all but as it is, if only for compatibility. Instead, you should propose putting the main content inside another element inside the body element, say content. Alternatively, you could try using article, but article has further semantics, and is thus unsuitable for wrapping the main content of an index (that is an index). IMO, HTML isn't a good format for indexes, but that's probably only IMO. In HTML, as you say, everything by default is body (about the same a a word document). But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. As previously stated, we can't change the semantics an content model of body. OTOH, it may be possible to put information that may be presented as a footer in head. Head poses strict constraints on both descendant nodes and position in the document (it must come first). It may thus be more suitable to specify a new element positioned _after_ /body containing information that belongs neither to head nor body. This would probably replace aside, which IMO has no place in body which is intended to be loosely linear. Also, I think that most information that's rendered in a footer should be marked up in the head, or as more general metadata fields such as RFC 2822 headers or file xattrs. Headers seem to consist mostly of navigational links, more appropriately marked up with links. Again, The inconvenient buddy element strikes back.
Re: [whatwg] Giving the body tag a new meaning.
On Wed, Mar 2, 2011 at 8:59 AM, usuario soyh...@gmail.com wrote: Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). In HTML, as you say, everything by default is body (about the same a a word document). But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. You are too much married to the traditional notion of the body of a document as known from paper. The meaning of body is here more akin to the meaning of the body content of an (e)mail. Everything that's the main content of a Web page is body. It may not be the most appropriate word for the kinds of Web pages you have in mind, but content may not be more appropriate as an element name either. I've long since decided that the exact meaning of a word differs based on context and trying to it's easier to adapt your perception that to adapt the world. In the Web context body is just what it is: the body of a Web page (technical semantics), not the body of the content of a Web page (content semantics). You could always reverse your argument and try to introduce a content element between header and footer (though: div does pretty well for this). But really, there are more important things to get right IMHO. Cheers, Silvia.
Re: [whatwg] Giving the body tag a new meaning.
You are too much married to the traditional notion of the body of a document as known from paper. The meaning of body is here more akin to the meaning of the body content of an (e)mail. Everything that's the main content of a Web page is body. It may not be the most appropriate word for the kinds of Web pages you have in mind, but content may not be more appropriate as an element name either. I've long since decided that the exact meaning of a word differs based on context and trying to it's easier to adapt your perception that to adapt the world. In the Web context body is just what it is: the body of a Web page (technical semantics), not the body of the content of a Web page (content semantics). You could always reverse your argument and try to introduce a content element between header and footer (though: div does pretty well for this). But really, there are more important things to get right IMHO. The same way we all are married with traditional sense of body, and see no reason to change it. If it do the work, why to run the risk?. offtopicThe same way with keep the doctype declaration that being mostly useless is required to not to 'trigger' quirks mode, we're suffering a past ghost./offtopic 2011/3/1 Silvia Pfeiffer silviapfeiff...@gmail.com On Wed, Mar 2, 2011 at 8:59 AM, usuario soyh...@gmail.com wrote: Let me put it in others words. Following the last example. Here is the way i see it, Everything inside a word document IS CONTENT (not body). In that document we may have or not a header, or a footer, but we always should have a body, in this word document, for convenience purposes text by default is intended to be body (hence no need to mark it as that). In HTML, as you say, everything by default is body (about the same a a word document). But the thing is that in HTML5, WE ARE making distinctions among *header* and *footer* content. My only counter here is why aren't we making distinctions of body content too? Is this semantic to you? body header/header footer/footer /body There is an obvious (may be not dangerous) semantic issue there. Why in the world a footer can be inside a body, aren't they siblings of a document? To me (but hope you too), something semantic would be this: content header/header body/body footer/footer /content I've been requested to solve a problem. Former has never been a problem, web as worked well in that way. I just am setting out a new way of thinking about html. Being more declarative. You are too much married to the traditional notion of the body of a document as known from paper. The meaning of body is here more akin to the meaning of the body content of an (e)mail. Everything that's the main content of a Web page is body. It may not be the most appropriate word for the kinds of Web pages you have in mind, but content may not be more appropriate as an element name either. I've long since decided that the exact meaning of a word differs based on context and trying to it's easier to adapt your perception that to adapt the world. In the Web context body is just what it is: the body of a Web page (technical semantics), not the body of the content of a Web page (content semantics). You could always reverse your argument and try to introduce a content element between header and footer (though: div does pretty well for this). But really, there are more important things to get right IMHO. Cheers, Silvia.
Re: [whatwg] Idea for having InputXML Or ClickXML for HTML5+
On Tue, Mar 1, 2011 at 1:05 AM, Narendra Sisodiya naren...@narendrasisodiya.com wrote: We can record mouse and keyboard activity in xml. There are many events which are resolution independent. for example mouse clicks, button press events . Now suppose you are dealing with some animation or game or just a slideshow. what you do ? you type some buttons from mouse or keyboard. Now if you can record the timeline of these events then we can play back at anytime. The idea is very interesting for having automated slideshows .. Do you mean that a web page should actually be able to actually control the user's mouse and keyboard? That's clearly not acceptable for security. What if the web page types: Ctrl-TCtrl-Lhttp://www.evil.com/download-virusEnterEnterEnter to go to a URL and skip any warnings about, e.g., installing untrusted plugins? Even if you limit it to synthesizing clicks that only take effect within the invoking webpage, you'd probably still run into security issues with cross-site content (clickjacking on steroids). What exactly do you mean by an automated slideshow? How would this feature help with that?
Re: [whatwg] context.arc and current point
On Thu, 2 Dec 2010, Andrea Canciani wrote: What will be the current point after an arc with endAngle-startAngle 2pi? The specification seems to say that the end point is defined to be the point at endAngle, but the path is required to be exactly a circle. The path is a circle but the end point is unaffected by this; it is defined as being endAngle aleng the circle's circumference, measured in radians clockwise from the positive x-axis. So for example: c.beginPath(); c.moveTo(20,20); c.arc(200, 200, 100, 0, 5*Math.PI, false); c.lineTo(380,380); c.stroke(); ...draws a line from the top left, diagonally down to the right edge of a circle, and then draws a line from the left edge of that circle diagonally down to the bottom right. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Session Management
On 3/1/11 5:29 PM, Ian Hickson wrote: I am still faced with the fact that there is no way to clear the HTTP authentication credentials cache. To some extent that's up to the browser. It logs you in, it can offer the ability to log you out. For what it's worth, Firefox even has UI for this -Boris
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, Feb 28, 2011 at 7:42 PM, Ian Hickson i...@hixie.ch wrote: Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. On Tue, Mar 1, 2011 at 9:12 AM, WeBMartians webmarti...@verizon.net wrote: For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows.
Re: [whatwg] Giving the body tag a new meaning.
It just seems to me that there are so many tags being added, why keep adding and adding? Down the line, it's gonna create nothing but abiguity in documents and mass confusion (especially in terms of rendering) as a result. I think that adding a content tag as children for header and footer or any other tag for that matter, is downright redundant and unneccesary. Them tags themselves are a content tag of sorts, they just have semanticly meaningful names. Lets face it, content may as well be a div as far as semantics go. The best solution would be to use what we have and just not require the use of the body tag at all. Have it remain as a legacy tag, but for the love of god, why would you add a new tag with almost the same purpose as the tag you propose nesting it in? That's my 2c. -Liam I neither write nor speak English natively, but I believe that the body element has to be preserved all but as it is, if only for compatibility. Instead, you should propose putting the main content inside another element inside the body element, say content. I agree, body must remain for compatibility, perhaps also able a new tag for its task, and deprecate its current meaning in future versions. content may be a good option as a header and footer sibling. And say not required, but if implemented, do it the right way.
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
Aryeh! You have made an ad-hominem attack: shame on you! I mention the Microsoft use cases only to save space. There are similar cases in the Linux and Macintosh realms. Judge an idea by its merits, not by its source (even if that source is as disreputable as I certainly am). You are correct that short duration time outs are, often, a terrible idea ... but the standard should not hobble the developer. Terrible ideas are a matter of opinion; my ideas are always grand and glorious, never terrible ... just ask me ... for I never lie and am always right. ...and consider this: just how would you handle the case in which the WWWeb page says: There is an approaching storm! Do you wish to close the dykes? No (let everybody drown) Yes (if you don't answer in an hour, this will be the default) To say that the WWWeb should not be used for this is in itself a terrible idea for you know that it will be used in this manner and neither of us can prevent such stupidities. By-the-Way - I advocate no change to alerts and such ... the above can be implemented with setTimeout without any changes to existing browsers. Best (and please understand my admonitions to be accompanied by affection and great respect)! BdG/WeBMartians === On 2011-03-01 19:46, Aryeh Gregor wrote: On Mon, Feb 28, 2011 at 7:42 PM, Ian Hicksoni...@hixie.ch wrote: Well we can't remove support for them from browsers, since millions of pages use them. Conformance checkers can't really complain about usage of those APIs, since they can't easily check JavaScript runtime compliance. So what would deprecating them mean? We could define script APIs, or features of them, as deprecated if browsers were willing to log some kind of notice to their error consoles when the feature is used. They all have error consoles with different reporting levels already, so it shouldn't be a pain for them to implement. They can have the deprecation warnings off by default so they don't clutter the output. At least Firefox already does this for some things, like document.getSelection() (although that message will probably go away in a future release). Of course, this would only be useful if we had a good alternative to recommend. Don't use alert(), use some giant JavaScript library instead is unlikely to be a very helpful message. But it would be nice for some of the crazier or more horrible APIs, if they have saner replacements. On Tue, Mar 1, 2011 at 9:12 AM, WeBMartianswebmarti...@verizon.net wrote: For comment 3, simply reference the use cases for Microsoft's AfxMsgBox, ::MessageBox and its derivatives. The time out is a well-received idea. Timeouts on dialogs are typically a terrible idea, and we shouldn't encourage them. They mean that if the user wasn't paying attention -- which could just mean they were looking at another tab, in browsers with tab-modal dialogs -- they never see the dialog. This is only useful in the case where the dialog is so useless you don't actually care if the user doesn't see it, in which case, why show it? In practice, authors often add timeouts to things that they expect the user to see, leaving the user confused if they don't wind up seeing it. IIRC, one of the nice little improvements I made to MediaWiki a few years ago was removing the last of the timed redirects from it. OS APIs are much more enthusiastic about permitting programmers to shoot themselves in the foot than web APIs. Microsoft specifically also cares much more about developers and less about users, because they depend on developers to write Windows-only apps and maintain Microsoft's lock-in, while users are forced to buy Windows anyway. Browsers, on the other hand, care very strongly about users, because users can easily switch to another browser at any time, while developers (authors) don't help or hurt them much as long as they write cross-browser code. So for multiple reasons, the fact that Windows supports something doesn't mean we should. You need to give actual specific use-cases, not just cite the fact that the feature exists in Windows.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
Great that this is getting attention spec-wise! First, could it be that the link you posted is broken (I get 404 - No such project. when clicking on it)? Also, reposting my initial comment I sent you, as you requested: In your draft you write: I'm not sure if my priorities in writing the algorithms here are correct. My goals were 1) make the algorithms as simple as possible, and 2) minimize surprising user-visible behavior (e.g., I clicked B but it didn't turn bold!). I didn't try to optimize the niceness of the resulting DOM at all, so for instance, when bolding abc idef/i br ghi you get babc /bi style=font-weight: bolddef/ib /bbr style=font-weight: boldb ghi/b instead of wrapping the whole thing in a single b. This is to avoid making the algorithm understand content models, but maybe it's worth revisiting later. Likewise, unbolding the middle word of bFoo bar baz/b produces bFoo span style=font-weight: normalbar/span baz/b instead of the simpler bFoo /bbarb baz/b. For now, the algorithm works, even if it produces messy DOMs. In general, I completely agree on 2), but I think there are several issues with 1) and the messy DOM part: .) If you produce messy DOMs, the DOM will get ever more messy the more the user edits stuff. IMHO producing nicer DOMs is more important than simple algorithms. Also, the messier the DOM, the harder it is for editors to cope with it. FWIW, for the new Browserscope RichText test suite I took the opposite stance: that the resulting DOM should be as concise as possible. .) In your results you mix element-based styling and CSS-based styling. I don't think that's a good idea, for 2 reasons (apart from looking inconsistent): 1.) you force complexity on code that perhaps could live with just simple element-based markup 2.) whether to produce element-based styling or CSS-based styling should be determined by whether or not StyleWithCSS was set. (Now, I'm not a huge fan of that command, but I do think it's important for users to have a way to specify this). Cheers, - Roland On Wed, Mar 2, 2011 at 3:36 AM, Aryeh Gregor simetrical+...@gmail.comwrote: Two or three weeks ago I began writing a specification for execCommand() and related functions. I don't have anything implementable yet -- it's very incomplete and there are known issues with the existing stuff. But I thought I'd post it for any early review comments on the direction I'm taking, particularly from implementers but also from anyone else familiar with the APIs (e.g., someone who's used them in practice): http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD The plan is that this should be merged into the main HTML spec, with a full test suite, by the end of August. Feedback appreciated.
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
On Wed, Mar 2, 2011 at 7:11 AM, Ryosuke Niwa rn...@webkit.org wrote: Great to see some spec'ing work here. Some issues with your document: - Styling a Range doesn't support styleWithCSS=false - Ignores possibility of JavaScript modifying DOM while your algorithm is running - This is actually consistent with TOT WebKit where dispatches of DOM mutation events are delayed until the editing command finishes its algorithm. I do point out that moving iframe, object, etc... result in unload events fired synchronously, at which point scripts can do whatever it pleases to do. - Ryosuke
Re: [whatwg] Idea for having InputXML Or ClickXML for HTML5+
On Wed, Mar 2, 2011 at 5:28 AM, Aryeh Gregor simetrical+...@gmail.comwrote: What exactly do you mean by an automated slideshow? How would this feature help with that? automated slideshow = slideshow where user need not to do next/forward etc, every slide will be having timings and Audio will be in sync with slides. I know this can be done using custom xml file and Javascript. ( https://docs.google.com/View?id=dhtsnnph_59gt2jjjdjpli=1 ) -- ┌─┐ │Narendra Sisodiya │http://narendrasisodiya.com └─┘
Re: [whatwg] set input.value when input element has composition string
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote: On Safari 5, even if textbox has IME composition string, text into textbox can be replaced by DOM/script. But other browser's behaviors are different, and this is no specification when textbox has composition string. Although IE, Chrome and Opera keep composition string after value is replaced by DOM, each behavior is different. This is the result for this test on each browsers. When textbox has IME composition string such as ABCDEFG, then script (textbox.value = 123;) is called, textbox becomes... 1. 123ABCDEFG (ABCDEFG keeps composition state and caret is after G). 2. 123 (composition string is removed). 3. ABCDEFG (ABCDEFG keeps composition state and caret is after G). Which behavior is right? 1 is Opera 11, 2 is Safari 5, and 3 is Chrome 10 and IE9. You must have tested Chrome improperly. We currently have a bug in Chrome. To see the bug, open the attached test and type nihao with Chinese IME on Windows or Mac. Then press down array key. The text is replaced by henhao but henha is still marked and looks as if I'm compositing henha but if I continue to type ma still with IME, then I observe that henhaomao is shown inside the input element. Once this bug is fixed, Chrome's behavior should match that of Safari 5. - Ryosuke
Re: [whatwg] Attitude and Direction of the WHATWG
On 3/1/2011 2:41 PM, Ian Hickson wrote: On Mon, 29 Nov 2010, Charles Pritchard wrote, in part (as, in the interests of making progress, I have not cited or responded to sections of the e-mail that did not include actionable feedback): On 11/27/2010 2:50 AM, Ian Hickson wrote: On Fri, 26 Nov 2010, Charles Pritchard wrote: I want to suggestion a reason for this impasse: the WHATWG intends to produce a scene-graph specification. Other activities are out of scope. I'm not sure what you really mean by scene-graph specification, so it's hard to comment on that specifically. Historically, and still today, the HTML language and its associated APIs are generally intended to primarily convey semantics (meaning, as opposed to presentation) so that they can be rendered in a media-independent way on any device. The HTML language has become even more semantic, less presentational, as CSS+SVG profiles are enhanced. These three sections of the HTML5 specs seem out of scope: Loading Webpages, Web application APIs and Communication I must admit surprise to the idea that loading webpages is not in scope of the spec that defines the format used for web pages. :-) The HTML spec is primarily an API spec, describing how a DOM tree can be manipulated from script and how it must react to user interaction. So the APIs seem entirely in scope. My understanding is that those items are covered by DOM, and WebIDL, which HTML inherits from. There's a bulk of APIs under the webapps group, covering much of the rest. I think that HTML spec is primarily a format spec, not an API spec. Unfortunately, contenteditable is less accessible to users than it should be. I'd like to see that addressed. Could you elaborate on how it is less accessible than it should be? I can't. But I can give some examples of shortcomings, as the Google word processor and Microsoft's editor are both quite short of coming anything near desktop word processing. The CK editor is certainly still a great example of pushing it as far as they can. My understanding is that rich text editing is really handed off to the UA (reading that from the ARIA spec under the Rich Text editor control), and that it's usability is a UA issue, not a scripting/format issue.
