Re: [whatwg] localStorage feedback
On Sun, Nov 1, 2009 at 3:53 AM, Darin Fisher da...@chromium.org wrote: On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da...@chromium.org wrote: You are right that the conditions are specific, but I don't know that that is the exhaustive list. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. What reasons? If these reasons are situations where it's fundamentally difficult, impossible, or non-performant to follow the spec, we should change the spec. Otherwise this would just be a bug in the UA. My point is that it is difficult to ensure that all situations where nesting can occur are understood apriori and that the list doesn't change over time. Because we are talking about multi-threading synchronization in a very complex system, I would much prefer a more isolated and less fragile solution. Unlock if yieldForStorageUpdates is called. Unlock when returning from script execution. Unlock if another attempt to lock occurs (any form of nesting). In the third case, I'd probably log something to the JS console to alert developers. I believe this simple implementation covers most of the cases enumerated in the spec, and it has the property of being easier to reason about and easier to support (more future proof). I think this would make the spec too dependent on implementation details. If your implementation needlessly or accidentally nests script execution --- e.g. by firing an event synchronously that should be, or could be, asynchronous --- then you'd still conform to your spec while the behaviour you present to authors gets quietly worse. If your description is (or can be, after suitable modifications) equivalent to what the spec currently says, but the equivalence is subtle (which it would be!), then I think they should *both* be in the spec, and the spec should say they're equivalent. Then if we find they're not equivalent, we clearly have a bug in the spec which must be fixed --- not carte blanche to proceed in an undesirable direction. It would be a sort of spec-level assertion. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. This example still sounds overly contrived to me. Nevertheless, it seems strange to say that because there might be a few unexpected race conditions, you have decided to allow a much larger set of unexpected race conditions. Why is it contrived? Because libraries tend to initially use plugins and move towards using core browser functionality, not the other way around. But even if these library issues aren't contrived, I don't see how they justify making things a lot more unpredictable for everyone. What will you do for Gecko when it supports content processes? Implement the spec, I hope! Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] model/: A 3D Equivalent to img/
I'm in perfect agreement regarding the rational behind having a model tag as I agree with having more semantic tags in HTML. However, I don't think a model tag would work as described as it would provide no real extra benefits and would just confuse document authors. The reason I feel this is basically down to the fact that 3d models don't have a visual representation in the same way that images do. A 3d model file is just a list of data that needs rendering into a 2d image for display. There isn't really a standardised way to do this (not in the same way as with images, with standardised png, jpg, bmp, etc. as well known and commonplace formats with commonplace methods of display), and on top of that it isn't a 3d model you a displaying, but a 2d representation (i.e. an img). If the representation is static, it isn't really a 3d model as it's just a 2d image, and if it isn't static then you need scripting support, drawing support, rendering and the whole host of items that require javascript hooks and would logically make such a model more suited to a 3d canvas (which I believe is to be supported eventually under a normal canvas tag). As such, I don't see a place for a model tag in the current environment as a merely semantic element, and adding more than just semantics to the tag would be overlapping it with other efforts. David W. 2009/11/2 Brian Blakely anewpage.me...@gmail.com Perfectly aware Simon, hence the proposition; a 3D model element is not an attempt to erase, but complement current efforts. Let me take this opportunity to clarify. model/ is neither redundant nor trampling current efforts, but filling an essential gap in the spec. This is why: 1) O3D and Khronos/Mozilla's efforts are JavaScript-based hooks into OS-level rendering APIs. They are akin to canvas/, providing a non-semantic viewport into content. This is good, but a new element is still necessary, even if you were to draw all 3D content into a canvas/. The reason is JavaScript. 2) You should not have to write JavaScript to embed 3D content. Imagine if you had to set up a canvas/ viewport every time you wanted to display an image. As it is in today's flatworld, developers should be able to convey content with only HTML and CSS knowledge. 3) X3D is a 3D equivalent to svg/, not img/, as I am proposing. model/ does not define how your 3D content will look (how font/-like! svg/ is already flying too close to that sun). It provides a hook into CSS, as well as granular, semantic control of content. The expectation is that it would link to a 3D model as defined in the src attribute, no further code required. This source could be in X3D format, or 3DS, MA, etc. Whichever the vendors eventually decide to support (hopefully the same format :) -Brian On Sun, Nov 1, 2009 at 8:31 PM, Simon Fraser s...@me.com wrote: On Oct 30, 2009, at 6:09 PM, Brian Blakely wrote: To ensure HTML remains semantic as the web makes its gradual transition to 3D rich interfaces and content, I am submitting a proposal for WHATWG's consideration. The below examples contain HTML as it exists now, the current working standard, and finally, a combination of both concepts. Please lend your thoughts and let's discuss a more semantic and accessible use of 3D. The fictional HTML and CSS above are just proposals, and I am not at all asserting these ideas are the best possible solution, only that there is a very real problem. Are you aware of the X3D and O3D efforts? http://www.web3d.org/x3d/specifications/ http://code.google.com/apis/o3d/ Simon
Re: [whatwg] Script Data tokenizer mode
Matt Hall wrote: When the script data state was added to the tokenizer, the tree construction algorithm was updated to switch the tokenizer into this state upon finding a start tag named script while in the in head insertion mode (9.2.5.7). I see that a corresponding change was not made to 9.5 about Parsing HTML Fragments as it still says to switch into the RAWTEXT state upon finding a script tag. Does anyone know if this difference is intentional, or did someone just forget to update the fragment parsing case? I think, due to the fact that no start tag has ever been emitted by the tokenizer, that RAWTEXT and the script data states should behave identically for the script element fragment case. (Once you take into account that there are no appropriate end tag token, all the careful casing for the comments effectively becomes nothing, and regardless of input everything will become character tokens. This is true of both the script data state and the RAWTEXT state: the latter is probably preferably due to its far lower complexity.) -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
[whatwg] WebStandrd for theme
Many blogging site like posterous has theme editor for their
blog/website. It is a xml file looks more like html. Following file
was a long file which I have edited and deleted the unnecessary
content. I think this is a non-standard way to design theme. Do we
have any standard to such requirement ? OR we do not need any standard
at all for such requirement.
PS: I have searched on FBML too. Google says, It is a propri. standard
of facebook.
== Sample Theme code =
?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
xmlns:fb=http://www.facebook.com/2008/fbml;
head
body
div id=centerbody
div class=posterous_bar
{PosterousBar}
/div
div class=posterous_header
a href={PosterousURL}img
src=/images/posterous-header.png width=75 height=35//a
/div
div class=posterous_flash
{block:Flash/}
/div
{block:HeaderImage}
div class=header_image
a href={SiteURL}img src={HeaderImageURL-500}
alt={Title} - {Description}//a
/div
{Else}
div class=header
h1a href={SiteURL}{Title}/a/h1
/div
div class=subhead
{block:Description}
{Description}nbsp;h2a
href=http://groups.google.com/group/iitdlug/;Join Mailing list /a
OR a href=http://lug-iitd.org; visit our website/a/h2
{/block:Description}
/div
{/block:HeaderImage}
{block:Show}
div class=back_to_blog
a href={SiteURL}laquo; Back to blog/a
/div
{/block:Show}
A LOT OF CODE DELETED ...
/body
/html
=
--
┌─┐
│Narendra Sisodiya ( नरेन्द्र सिसोदिया )
│Web : http://narendra.techfandu.org
│Twitter : http://tinyurl.com/dz7e4a
└─┘
Re: [whatwg] localStorage feedback
On Mon, Nov 2, 2009 at 1:28 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sun, Nov 1, 2009 at 3:53 AM, Darin Fisher da...@chromium.org wrote: On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da...@chromium.orgwrote: You are right that the conditions are specific, but I don't know that that is the exhaustive list. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. What reasons? If these reasons are situations where it's fundamentally difficult, impossible, or non-performant to follow the spec, we should change the spec. Otherwise this would just be a bug in the UA. My point is that it is difficult to ensure that all situations where nesting can occur are understood apriori and that the list doesn't change over time. Because we are talking about multi-threading synchronization in a very complex system, I would much prefer a more isolated and less fragile solution. Unlock if yieldForStorageUpdates is called. Unlock when returning from script execution. Unlock if another attempt to lock occurs (any form of nesting). In the third case, I'd probably log something to the JS console to alert developers. I believe this simple implementation covers most of the cases enumerated in the spec, and it has the property of being easier to reason about and easier to support (more future proof). I think this would make the spec too dependent on implementation details. If your implementation needlessly or accidentally nests script execution --- e.g. by firing an event synchronously that should be, or could be, asynchronous --- then you'd still conform to your spec while the behaviour you present to authors gets quietly worse. If your description is (or can be, after suitable modifications) equivalent to what the spec currently says, but the equivalence is subtle (which it would be!), then I think they should *both* be in the spec, and the spec should say they're equivalent. Then if we find they're not equivalent, we clearly have a bug in the spec which must be fixed --- not carte blanche to proceed in an undesirable direction. It would be a sort of spec-level assertion. I think the spec currently calls attention to only some situations that could lead to nesting of implicitly acquired storage locks. I previously described some other situations, which you and others indicated should be treated as WebKit and IE bugs. I didn't look very far to dig those up. After some more thought, I came up with these additional cases that the spec doesn't cover: 1a) Given a page (domain A) containing an iframe (domain B), have the outer page navigate the inner frame to about:blank. This navigation completes synchronously, and the unload handler for the iframe runs before the navigation request completes. This is true of all browsers. 1b) Suppose the inner page has a pending XMLHttpRequest when the outer frame navigates the inner frame. The XHR's onabort handler would run before the navigation to about:blank completes. 2) Set a break point in the Mozilla JS debugger. This runs a nested event loop each time you single step so that it can drive the rest of the browser UI. 3) Install a Firefox extension that runs a nested event loop in response to an event generated by content. I debugged many Firefox crashes resulting from extensions that do this kind of thing for various reasons. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. This example still sounds overly contrived to me. Nevertheless, it seems strange to say that because there might be a few unexpected race conditions, you have decided to allow a much larger set of unexpected race conditions. Why is it contrived? Because libraries tend to initially use plugins and move towards using core browser functionality, not the other way around. But even if these library issues aren't contrived, I don't see how they justify making things a lot more unpredictable for everyone. I'm not convinced. Look at Google Maps and street view. Gmail uses more Flash now than it used to. Wave uses Gears for a variety of little things. There's a cool video gadget that swaps between HTML5 video or Flash depending on the browser and the target media. What will you do for Gecko when it supports content processes? Implement the spec, I hope! It seems odd to me that this behavior was put into the spec without any implementation experience to guide it. The only multi-process implementations that I know of do not have a storage mutex. -Darin
Re: [whatwg] WebStandrd for theme
narendra sisodiya schrieb:
Many blogging site like posterous has theme editor for their
blog/website. It is a xml file looks more like html. Following file
was a long file which I have edited and deleted the unnecessary
content. I think this is a non-standard way to design theme. Do we
have any standard to such requirement ? OR we do not need any standard
at all for such requirement.
PS: I have searched on FBML too. Google says, It is a propri. standard
of facebook.
In the document you provided I couldn't find any tag using the
fb-namespace. All the other things, like {something}, are a typical
method to mark up things to be inserted in Templates. They are processed
by a templating engine. And I really do think that things like this
don't belong to HTML, they are many templating systems, many PHP
developers have their own (as I do) using markup that's convenient for them.
Nikita Popov
Re: [whatwg] WebStandrd for theme
On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov pri...@ni-po.com wrote:
narendra sisodiya schrieb:
Many blogging site like posterous has theme editor for their
blog/website. It is a xml file looks more like html. Following file
was a long file which I have edited and deleted the unnecessary
content. I think this is a non-standard way to design theme. Do we
have any standard to such requirement ? OR we do not need any standard
at all for such requirement.
PS: I have searched on FBML too. Google says, It is a propri. standard
of facebook.
In the document you provided I couldn't find any tag using the fb-namespace.
The deleted content was having fb markups, My concern was more on
{{something}} type of things. To me it looks highly non-standard.
All the other things, like {something}, are a typical method to mark up
things to be inserted in Templates. They are processed by a templating
engine. And I really do think that things like this don't belong to HTML,
they are many templating systems, many PHP developers have their own (as I
do) using markup that's convenient for them.
Nikita Popov
--
┌─┐
│Narendra Sisodiya ( नरेन्द्र सिसोदिया )
│Web : http://narendra.techfandu.org
│Twitter : http://tinyurl.com/dz7e4a
└─┘
Re: [whatwg] model/: A 3D Equivalent to img/
David,
Excellent perspectives, and there are certainly format decisions that have
to be made as a matter of course, just as there have been for video/.
I do not agree with two of your points:
* A static 3D rendering is equal to a 2D bitmap
* JavaScript is necessary to display 3D content
My brief counter-points:
* 2D bitmaps are only partially compatible with 3D CSS - they are still
always flat
* This includes canvas/, which is still a 2D bitmap, not actually a 3D
object
A JavaScript-Only Approach is Inferior Because:
* canvas/ is being purposed as a viewport into 3D content, a function the
browser itself should serve
* 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript
alone
* Using only 3D JavaScript, the code required in order to serve rich user
interfaces is bandwidth intensive, working against one of the key benefits
of using web standards
Explanation and Supporting Examples
These assumptions are partially the fault of my primordial example, as that
example's purpose was to illustrate these concepts clearly, not demonstrate
an application of the technology. The goal of model/ is not merely to
serve 3D content, but to allow designers and developers to *lay out web
content and applications in 3D*. Let's think of this concept as 3D HTML.
canvas/ is not a solution. It is rendering 3D content inside a viewport,
when the browser itself should be a viewport to 3D content. One
alternative, creating a giant canvas/ and filling it with fallback
content, is coding twice - not good.
The foundations of 3D CSS (a la Webkit -
http://webkit.org/blog/386/3d-transforms/) and 3D JavaScript (WebGL/O3D) are
being laid out, but there is no HTML equivalent to cement a truly 3D design
platform on the web.
If we draw 3D design to its logical conclusion, rich user interfaces, then
the usefulness and necessity of 3D HTML becomes more apparent. I will
support this statement with an advanced example, which will demonstrate the
inadequacies of 2D design, and the gaps in currently-existing potential
standards.
DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW
--
The below snippets will illustrate how a page would lay out such an
interface in three ways: 1) A 2D implementation you will see today; 2) a
combination of fictional 3D HTML and 3D CSS; 3) only 3D CSS, 3D JavaScript
and canvas/.
On hover, each planet will rotate about its own axis.
2D HTML CSS
---
style
ul {
* Background image of space
}
li {
* Absolutely positioned to correlate perspective
}
a {
* Block
* Negative indentation, hiding text
}
a.(planet name) {
* Background image of each planet
* Height/Width of each background image (alternatively a large
height/width in the anchor definition above, centering each image on X,Y
axes)
}
/style
h1The Solar System in 3/4/h1
ul
li
a class=sun href=sun.htmlThe Sun/a
/li
li
a class=mercury href=mercury.htmlMercury/a
/li
li
a class=venus href=venus.htmlVenus/a
/li
...
/ul
script
* Slideshow background script attached to each anchor, listening for
mouseover and mouseout
/script
3D HTML CSS (notes in parentheses)
---
style
div {
* Background image of space
}
ul {
* Rotate to 3/4 view (We can no longer display a background on this
element, because it will become wafer-like when rotated; a model/ will
maintain its desired shape, as it is really 3D.)
}
model {
(some of the work will already be done for you by the ul rotation)
* Rotate to proper perspective
* Translate to desired depth/position
(in the syntax of -webkit-transition and -webkit-rotate, currently in
use today)
* transition: rotate 3s ease-out;
}
model:hover {
* rotateY(360deg);
}
/style
h1The Solar System in 3/4h1
div
ul
li
a href=sun.html
model src=sun.xml alt=The Sun /
/a
/li
li
a href=mercury.html
model src=mercury.xml alt=Mercury /
/a
/li
li
a href=venus.html
model src=venus.xml alt=Venus /
/a
/li
...
/ul
/div
3D JAVASCRIPT, 2D HTML CSS
---
style
canvas {
* Height/Width of viewport
}
/style
h1The Solar System in 3/4/h1
canvas id=solar-system
!-- ALT CONTENT FOR BROWSERS NOT SUPPORTING canvas/ --
(Herein: Code from Example 1)
/canvas
script
(the following is a non-custom snippet from O3D's simple example --
webGL's implementation is slightly cleaner)
function loadFile(context, path) {
function callback(pack, parent, exception) {
enableInput(true);
if (exception) {
alert(Could not load: + path + \n + exception);
g_loadingElement.innerHTML = loading failed.;
} else {
[whatwg] Editorial changes to spec go here?
I have a couple of editorial changes to suggest for the spec. Is this the right place to post them? thanks, Liz Elizabeth Castro my web site: http://www.elizabethcastro.com my blog: http://www.pigsgourdsandwikis.com
Re: [whatwg] Editorial changes to spec go here?
On Mon, Nov 2, 2009 at 4:14 PM, Elizabeth Castro lcas...@cookwood.com wrote: I have a couple of editorial changes to suggest for the spec. Is this the right place to post them? Yes, or simply submit them as bugs directly from the spec. ~TJ
[whatwg] Fwd: model/: A 3D Equivalent to img/
Oops, hit 'reply' instead of 'reply to all'. Forwarding to the list now (sorry for the duplicate, brian) Brian, I agree that a static 3d rendering isn't really equal to a 2d bitmap, but I think that the distinction will be lost on most people. As to javascript not being required? I think that javascript (or some other scripting) will most certainly be required for any form of interactive 3d scene, in exactly the same way as HTML currently requires javascript for interactive elements currently (or some form of plugin driven by a different language). The rest of your expanded example doesn't fill me with joy though. From the sounds of things, you are envisaging a complete re-engineering of HTML from it's current format of a document description language with some presentation and media elements put in to make it extremely useful and versatile (and already fraught with legacy problems and some syntactic ambiguities) into a language for describing the placement and content of a full interactive 3d environment and 3d user interface. The problems I see with this are: * A re-engineering like this would leave the language a complete shambles. There would be legacy elements all over the place, conflicts galore and I doubt the result would be usable at all. * 3d interfaces are barely understood currently, and a lot of the research in the area seems to point to them actually just not being intuitive. Why butcher HTML to add support for this when there isn't even necessarily a use case yet? * Picking a 3d format to standardise around would be non-trivial and cause even more fragmentation of the web community. Should the programmable API resemble DirectX? OpenGL? Should the scene description be .3ds inspired, maya inspired, VRML inspired or one of the XML based formats also mentioned? Should it be something new? * Fallback content would become a nightmare from 3d to 2d. It's bad enough currently, just dealing with fallbacks from scripted content to static content. Imagine the problem magnified my having to collapse a dimension as well. Now I'm not saying that a 3d language for the web isn't a good idea. I think the idea has some huge potential. I just don't think that layering it on top of HTML with all of it's legacy concerns and also it's document centric model is a good idea for the above practical concerns. David W. 2009/11/2 Brian Blakely anewpage.me...@gmail.com David, Excellent perspectives, and there are certainly format decisions that have to be made as a matter of course, just as there have been for video/. I do not agree with two of your points: * A static 3D rendering is equal to a 2D bitmap * JavaScript is necessary to display 3D content My brief counter-points: * 2D bitmaps are only partially compatible with 3D CSS - they are still always flat * This includes canvas/, which is still a 2D bitmap, not actually a 3D object A JavaScript-Only Approach is Inferior Because: * canvas/ is being purposed as a viewport into 3D content, a function the browser itself should serve * 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript alone * Using only 3D JavaScript, the code required in order to serve rich user interfaces is bandwidth intensive, working against one of the key benefits of using web standards Explanation and Supporting Examples These assumptions are partially the fault of my primordial example, as that example's purpose was to illustrate these concepts clearly, not demonstrate an application of the technology. The goal of model/ is not merely to serve 3D content, but to allow designers and developers to *lay out web content and applications in 3D*. Let's think of this concept as 3D HTML. canvas/ is not a solution. It is rendering 3D content inside a viewport, when the browser itself should be a viewport to 3D content. One alternative, creating a giant canvas/ and filling it with fallback content, is coding twice - not good. The foundations of 3D CSS (a la Webkit - http://webkit.org/blog/386/3d-transforms/) and 3D JavaScript (WebGL/O3D) are being laid out, but there is no HTML equivalent to cement a truly 3D design platform on the web. If we draw 3D design to its logical conclusion, rich user interfaces, then the usefulness and necessity of 3D HTML becomes more apparent. I will support this statement with an advanced example, which will demonstrate the inadequacies of 2D design, and the gaps in currently-existing potential standards. DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW -- The below snippets will illustrate how a page would lay out such an interface in three ways: 1) A 2D implementation you will see today; 2) a combination of fictional 3D HTML and 3D CSS; 3) only 3D CSS, 3D JavaScript and canvas/. On hover, each planet will rotate about its own axis. 2D HTML CSS
[whatwg] Contingency plans
I've noticed a couple of instances in which the spec gives the content model for a given element, like for example, the hgroup element contains one or more of h1, h2, etc., and then specifies what should happen even if the element doesn't contain what it's supposed to, as here where we learn what an hgroup's rank should be if it is empty: The rank of an hgroup element is the rank of the highest-ranked h1– h6 element descendant of the hgroup element, if there are any such elements, or otherwise the same as for an h1 element (the highest rank). It seems like it's implying that it's OK for the hgroup to not follow its own content model. Or is it just saying what should happen if it is erroneously empty? thanks, Liz
[whatwg] Typo in 4.4.10
The third to last word in this line: If node has an ancestor element that is a article element should be an Liz
[whatwg] Sectioning
In 4.4.11, it says Sectioning content elements are always considered subsections of their nearest ancestor element of sectioning content, regardless of what implied sections other headings may have created. Does that line mean that a section element is *not* a subsection of the nearest implied section? So, if there is no other explicit sectioning content, as in the example given, then what would the section element be a subsection of? I don't get why Thud ends up on an equal level as Quux and Bar. It seems like as a section under h2 it should be a subsection of that Quux h2, just as the implied Bar section is a subsection of the implied Foo section. thanks, Liz
Re: [whatwg] model/: A 3D Equivalent to img/
David, To respond to your points: * I'm a bit confused as to what re-engineering you are referring. You say layering on top of HTML at the end of your response, but none of the example code in this thread amounts to an intrinsic change to HTML whatsoever (it actually riffs heavily on video/), so I would appreciate it if you could pull out some snippets to make your statement more clear. * We aren't going to learn how to use 3D if we don't have the very best tools at our disposal. With new talent and new technology come new opportunities. * Picking a format is not a part of this proposal, but yes it is necessary and no it does not sound like a cake walk. One could say this about nearly every point of HTML5. * Designers will, as always, work off of their audiences, and many technologies in HTML5 will not be useful immediately. Browsers which do not support 3D HTML will likely also not support 3D CSS and 3D JavaScript, but those technologies are no less compelling and necessary for it. -Brian On Mon, Nov 2, 2009 at 5:36 PM, David Workman workm...@gmail.com wrote: Brian, I agree that a static 3d rendering isn't really equal to a 2d bitmap, but I think that the distinction will be lost on most people. As to javascript not being required? I think that javascript (or some other scripting) will most certainly be required for any form of interactive 3d scene, in exactly the same way as HTML currently requires javascript for interactive elements currently (or some form of plugin driven by a different language). The rest of your expanded example doesn't fill me with joy though. From the sounds of things, you are envisaging a complete re-engineering of HTML from it's current format of a document description language with some presentation and media elements put in to make it extremely useful and versatile (and already fraught with legacy problems and some syntactic ambiguities) into a language for describing the placement and content of a full interactive 3d environment and 3d user interface. The problems I see with this are: * A re-engineering like this would leave the language a complete shambles. There would be legacy elements all over the place, conflicts galore and I doubt the result would be usable at all. * 3d interfaces are barely understood currently, and a lot of the research in the area seems to point to them actually just not being intuitive. Why butcher HTML to add support for this when there isn't even necessarily a use case yet? * Picking a 3d format to standardise around would be non-trivial and cause even more fragmentation of the web community. Should the programmable API resemble DirectX? OpenGL? Should the scene description be .3ds inspired, maya inspired, VRML inspired or one of the XML based formats also mentioned? Should it be something new? * Fallback content would become a nightmare from 3d to 2d. It's bad enough currently, just dealing with fallbacks from scripted content to static content. Imagine the problem magnified my having to collapse a dimension as well. Now I'm not saying that a 3d language for the web isn't a good idea. I think the idea has some huge potential. I just don't think that layering it on top of HTML with all of it's legacy concerns and also it's document centric model is a good idea for the above practical concerns. David W. 2009/11/2 Brian Blakely anewpage.me...@gmail.com David, Excellent perspectives, and there are certainly format decisions that have to be made as a matter of course, just as there have been for video/. I do not agree with two of your points: * A static 3D rendering is equal to a 2D bitmap * JavaScript is necessary to display 3D content My brief counter-points: * 2D bitmaps are only partially compatible with 3D CSS - they are still always flat * This includes canvas/, which is still a 2D bitmap, not actually a 3D object A JavaScript-Only Approach is Inferior Because: * canvas/ is being purposed as a viewport into 3D content, a function the browser itself should serve * 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript alone * Using only 3D JavaScript, the code required in order to serve rich user interfaces is bandwidth intensive, working against one of the key benefits of using web standards Explanation and Supporting Examples These assumptions are partially the fault of my primordial example, as that example's purpose was to illustrate these concepts clearly, not demonstrate an application of the technology. The goal of model/ is not merely to serve 3D content, but to allow designers and developers to *lay out web content and applications in 3D*. Let's think of this concept as 3D HTML. canvas/ is not a solution. It is rendering 3D content inside a viewport, when the browser itself should be a viewport to 3D content. One alternative, creating a giant canvas/ and filling it
Re: [whatwg] model/: A 3D Equivalent to img/
Additional clarification on this proposal: A model Element Never Becomes a Wafer --- Right now, if you try to act on conventional HTML elements with 3D CSS, those elements become wafers. See here: http://webkit.org/blog/386/3d-transforms/ One of the primary goals of embedding a 3D object (even a static, non-interactive one) is that it can be rotated and translated in CSS without losing its dimensional properties. globe.xml will always appear round, at any rotation degree, rather than like a cracker, as a canvas/ or img/ would. -Brian MB
Re: [whatwg] model/: A 3D Equivalent to img/
On Nov 2, 2009, at 3:41 PM, Brian Blakely wrote: Additional clarification on this proposal: A model Element Never Becomes a Wafer --- Right now, if you try to act on conventional HTML elements with 3D CSS, those elements become wafers. See here: http://webkit.org/blog/386/3d-transforms/ One of the primary goals of embedding a 3D object (even a static, non-interactive one) is that it can be rotated and translated in CSS without losing its dimensional properties. globe.xml will always appear round, at any rotation degree, rather than like a cracker, as a canvas/ or img/ would. I disagree. In order to do this, you have to have some 3D space in which the model element lives, and you need to be able to specify clipping planes, perspective etc. If elements are rotated *inside* the model, then of course they maintain their 3D space. But the model element itself has to be planar, and has to interact with other elements on the page just as any other HTML element does. Simon
Re: [whatwg] localStorage feedback
On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher da...@chromium.org wrote: 1a) Given a page (domain A) containing an iframe (domain B), have the outer page navigate the inner frame to about:blank. This navigation completes synchronously, and the unload handler for the iframe runs before the navigation request completes. This is true of all browsers. 1b) Suppose the inner page has a pending XMLHttpRequest when the outer frame navigates the inner frame. The XHR's onabort handler would run before the navigation to about:blank completes. These are really the same problem: synchronous cross-domain about:blank navigation. If navigation to about:blank has to be synchronous, then I guess it needs to drop the lock, at least in the cross-domain case. 2) Set a break point in the Mozilla JS debugger. This runs a nested event loop each time you single step so that it can drive the rest of the browser UI. 3) Install a Firefox extension that runs a nested event loop in response to an event generated by content. I debugged many Firefox crashes resulting from extensions that do this kind of thing for various reasons. These are internal Mozilla issues and should not be allowed to influence the design of the Web platform. They'll probably change for multi-process anyway. I'm not convinced. Look at Google Maps and street view. Gmail uses more Flash now than it used to. For new features, sure. But are they reimplementing existing browser-based functionality to use plugins instead? What will you do for Gecko when it supports content processes? Implement the spec, I hope! It seems odd to me that this behavior was put into the spec without any implementation experience to guide it. The only multi-process implementations that I know of do not have a storage mutex. Lots of things are in the spec without implementation experience. I think we have time to collect more experience on this issue with multi-process browsers and revise the spec in light of it. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] model/: A 3D Equivalent to img/
Simon, * Though it does not have properties for clipping, Webkit's proposed implementation of 3D CSS does have them for perspective. Clipping, lighting, texture stretching and additional considerations could also be a part of that spec, but those are discussions for the CSS WG. Without a 3D media element, none of that work can be done. * This proposal of a model can be considered a direct 3D analog to a PNG, and its height and width could certainly be modified in the X-Y axes on which 2D elements live, affecting document flow in that fashion. * Webkit's implementation of CSS does not remove 3D-ified elements from the document flow, the perspective of that flow is merely changed only for the affected elements. 3D and 2D elements can exist side-by-side that way as well. -Brian
Re: [whatwg] model/: A 3D Equivalent to img/
Spinning Cube Example
Integrating 3D Media Type with Current Techniques
---
(note: the only significant difference between this and
currently implemented technology is the media type
and additional CSS properties suited specifically for
3D presentation)
style
* Static presentation for cube
/style
model id=cube src=cube.xml /
script
var cube = document.getElementById('cube');
var rotDegree = 0;
var rotation = setInterval(function() {
cube.style.WebkitTransform = rotateY(+rotDegree+deg);
cube.style.MozTransform = rotateY(+rotDegree+deg);
rotDegree+=15;
if(rotDegree === 360) {
rotDegree = 0;
}
}, 20);
/script
Re: [whatwg] model/: A 3D Equivalent to img/
* 2D bitmaps are only partially compatible with 3D CSS - they are still always
flat3D object will finally be present as a 2d bitmap. there are always a
process called rendering.you idea may be similar with the VRML, such as
Box(x,y,z,w,l,h) but VRML still need some ActiveX to render it into bitmap.*
This includes canvas/, which is still a 2D bitmap, not actually a 3D object
people now are working on the CanvasRenderingContext3D,but rendering
efficiency is a big problem I think.
From: anewpage.me...@gmail.com
Date: Mon, 2 Nov 2009 14:16:37 -0500
To: workm...@gmail.com
CC: whatwg@lists.whatwg.org
Subject: Re: [whatwg] model/: A 3D Equivalent to img/
David,
Excellent perspectives, and there are certainly format decisions that have to
be made as a matter of course, just as there have been for video/.
I do not agree with two of your points:
* A static 3D rendering is equal to a 2D bitmap
* JavaScript is necessary to display 3D content
My brief counter-points:
* 2D bitmaps are only partially compatible with 3D CSS - they are still always
flat* This includes canvas/, which is still a 2D bitmap, not actually a 3D
object
A JavaScript-Only Approach is Inferior Because:
* canvas/ is being purposed as a viewport into 3D content, a function the
browser itself should serve
* 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript alone
* Using only 3D JavaScript, the code required in order to serve rich user
interfaces is bandwidth intensive, working against one of the key benefits of
using web standards
Explanation and Supporting Examples
These assumptions are partially the fault of my primordial example, as that
example's purpose was to illustrate these concepts clearly, not demonstrate an
application of the technology. The goal of model/ is not merely to serve 3D
content, but to allow designers and developers to *lay out web content and
applications in 3D*. Let's think of this concept as 3D HTML.
canvas/ is not a solution. It is rendering 3D content inside a
viewport, when the browser itself should be a viewport to 3D content. One
alternative, creating a giant canvas/ and filling it with fallback content,
is coding twice - not good.
The foundations of 3D CSS (a la Webkit -
http://webkit.org/blog/386/3d-transforms/) and 3D JavaScript (WebGL/O3D) are
being laid out, but there is no HTML equivalent to cement a truly 3D design
platform on the web.
If we draw 3D design to its logical conclusion, rich user interfaces, then the
usefulness and necessity of 3D HTML becomes more apparent. I will support this
statement with an advanced example, which will demonstrate the inadequacies of
2D design, and the gaps in currently-existing potential standards.
DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW
--
The below snippets will illustrate how a page would lay out such an interface
in three ways: 1) A 2D implementation you will see today; 2) a combination of
fictional 3D HTML and 3D CSS; 3) only 3D CSS, 3D JavaScript and canvas/.
On hover, each planet will rotate about its own axis.
2D HTML CSS
---
style
ul {
* Background image of space
}
li {
* Absolutely positioned to correlate perspective
}
a {
* Block
* Negative indentation, hiding text
}
a.(planet name) {
* Background image of each planet
* Height/Width of each background image (alternatively a large height/width
in the anchor definition above, centering each image on X,Y axes)
}
/style
h1The Solar System in 3/4/h1
ul
li
a class=sun href=sun.htmlThe Sun/a
/li
li
a class=mercury href=mercury.htmlMercury/a
/li
li
a class=venus href=venus.htmlVenus/a
/li
...
/ul
script
* Slideshow background script attached to each anchor, listening for
mouseover and mouseout
/script
3D HTML CSS (notes in parentheses)
---
style
div {
* Background image of space
}
ul {
* Rotate to 3/4 view (We can no longer display a background on this
element, because it will become wafer-like when rotated; a model/ will
maintain its desired shape, as it is really 3D.)
}
model {
(some of the work will already be done for you by the ul rotation)
* Rotate to proper perspective
* Translate to desired depth/position
(in the syntax of -webkit-transition and -webkit-rotate, currently in use
today)
* transition: rotate 3s ease-out;
}
model:hover {
* rotateY(360deg);
}
/style
h1The Solar System in 3/4h1
div
ul
li
a href=sun.html
model src=sun.xml alt=The Sun /
/a
/li
li
a href=mercury.html
model src=mercury.xml alt=Mercury /
/a
/li
li
a href=venus.html
model src=venus.xml
Re: [whatwg] model/: A 3D Equivalent to img/
CYp,
We are speaking about a native, semantic 3D media type. It is
inherently compatible with 3D CSS and requires no additional code to
display. This is very different from a 2D rendering based on 3D
properties (as with VRML and canvas/).
-Brian
2009/11/2 CYp tccy...@hotmail.com:
* 2D bitmaps are only partially compatible with 3D CSS - they are still
always flat
3D object will finally be present as a 2d bitmap. there are always a
process called rendering.
you idea may be similar with the VRML, such as Box(x,y,z,w,l,h) but VRML
still need some ActiveX to render it into bitmap.
* This includes canvas/, which is still a 2D bitmap, not actually a 3D
object
people now are working on the CanvasRenderingContext3D,but rendering
efficiency is a big problem I think.
From: anewpage.me...@gmail.com
Date: Mon, 2 Nov 2009 14:16:37 -0500
To: workm...@gmail.com
CC: whatwg@lists.whatwg.org
Subject: Re: [whatwg] model/: A 3D Equivalent to img/
David,
Excellent perspectives, and there are certainly format decisions that have
to be made as a matter of course, just as there have been for video/.
I do not agree with two of your points:
* A static 3D rendering is equal to a 2D bitmap
* JavaScript is necessary to display 3D content
My brief counter-points:
* 2D bitmaps are only partially compatible with 3D CSS - they are still
always flat
* This includes canvas/, which is still a 2D bitmap, not actually a 3D
object
A JavaScript-Only Approach is Inferior Because:
* canvas/ is being purposed as a viewport into 3D content, a function the
browser itself should serve
* 3D HTML/CSS is more facilitative to 3D design work than 3D JavaScript
alone
* Using only 3D JavaScript, the code required in order to serve rich user
interfaces is bandwidth intensive, working against one of the key benefits
of using web standards
Explanation and Supporting Examples
These assumptions are partially the fault of my primordial example, as that
example's purpose was to illustrate these concepts clearly, not demonstrate
an application of the technology. The goal of model/ is not merely to
serve 3D content, but to allow designers and developers to *lay out web
content and applications in 3D*. Let's think of this concept as 3D HTML.
canvas/ is not a solution. It is rendering 3D content inside a viewport,
when the browser itself should be a viewport to 3D content. One
alternative, creating a giant canvas/ and filling it with fallback
content, is coding twice - not good.
The foundations of 3D CSS (a la Webkit -
http://webkit.org/blog/386/3d-transforms/) and 3D JavaScript (WebGL/O3D) are
being laid out, but there is no HTML equivalent to cement a truly 3D design
platform on the web.
If we draw 3D design to its logical conclusion, rich user interfaces, then
the usefulness and necessity of 3D HTML becomes more apparent. I will
support this statement with an advanced example, which will demonstrate the
inadequacies of 2D design, and the gaps in currently-existing potential
standards.
DISPLAYING THE SOLAR SYSTEM IN A 3/4 VIEW
--
The below snippets will illustrate how a page would lay out such an
interface in three ways: 1) A 2D implementation you will see today; 2) a
combination of fictional 3D HTML and 3D CSS; 3) only 3D CSS, 3D JavaScript
and canvas/.
On hover, each planet will rotate about its own axis.
2D HTML CSS
---
style
ul {
* Background image of space
}
li {
* Absolutely positioned to correlate perspective
}
a {
* Block
* Negative indentation, hiding text
}
a.(planet name) {
* Background image of each planet
* Height/Width of each background image (alternatively a large
height/width in the anchor definition above, centering each image on X,Y
axes)
}
/style
h1The Solar System in 3/4/h1
ul
li
a class=sun href=sun.htmlThe Sun/a
/li
li
a class=mercury href=mercury.htmlMercury/a
/li
li
a class=venus href=venus.htmlVenus/a
/li
...
/ul
script
* Slideshow background script attached to each anchor, listening for
mouseover and mouseout
/script
3D HTML CSS (notes in parentheses)
---
style
div {
* Background image of space
}
ul {
* Rotate to 3/4 view (We can no longer display a background on this
element, because it will become wafer-like when rotated; a model/ will
maintain its desired shape, as it is really 3D.)
}
model {
(some of the work will already be done for you by the ul rotation)
* Rotate to proper perspective
* Translate to desired depth/position
(in the syntax of -webkit-transition and -webkit-rotate, currently in
use today)
* transition: rotate 3s ease-out;
}
model:hover {
* rotateY(360deg);
}
Re: [whatwg] Editorial changes to spec go here?
On Mon, 2 Nov 2009, Elizabeth Castro wrote: I have a couple of editorial changes to suggest for the spec. Is this the right place to post them? Yes. If they're trivial, e.g. typos, then the easiest way is to use the submit review comments feature at the bottom of the screen when viewing the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Contingency plans
On Mon, 2 Nov 2009, Elizabeth Castro wrote: I've noticed a couple of instances in which the spec gives the content model for a given element, like for example, the hgroup element contains one or more of h1, h2, etc., and then specifies what should happen even if the element doesn't contain what it's supposed to, as here where we learn what an hgroup's rank should be if it is empty: The rank of an hgroup element is the rank of the highest-ranked h1�h6 element descendant of the hgroup element, if there are any such elements, or otherwise the same as for an h1 element (the highest rank). It seems like it's implying that it's OK for the hgroup to not follow its own content model. Or is it just saying what should happen if it is erroneously empty? The latter. You can hide all the implementation-specific stuff by switching the view mode of the spec using the widget at the top right of the document to Hide UA text. There's also a third mode, Highlight UA text, which highlights in red the bits that are hidden in the Hide UA text mode. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] model/: A 3D Equivalent to img/
On Nov 2, 2009, at 4:26 PM, Brian Blakely wrote: * Though it does not have properties for clipping, Webkit's proposed implementation of 3D CSS does have them for perspective. Clipping, lighting, texture stretching and additional considerations could also be a part of that spec, but those are discussions for the CSS WG. Without a 3D media element, none of that work can be done. Implementing your proposal would require that the model and surrounding CSS-transformed content be implemented via the same 3D engine, sharing a common coordinate system. That vastly increases the burden placed on an implementor of 3D transforms: suddenly wafers in space are non longer sufficient, and you need a new engine with support for all the features required by your model / content (which also needs to be specified somewhere). You can't just glue a 3D-rendered model into an environment with CSS-3D-transformed HTML elements and expect them to share a common 3D space. * This proposal of a model can be considered a direct 3D analog to a PNG, and its height and width could certainly be modified in the X-Y axes on which 2D elements live, affecting document flow in that fashion. A 3D analog for img / is a fine goal, but the primary issue is that there is no 3D file format which is accepted as a standard for this kind of use. Even if there were, the analogy breaks down because 3D is structured data; the author wants to be able to address certain objects in the 3D scene in order to animate them, or do click handling on them, or whatever. There is much more complexity here than there is with images. In this sense, model is as much a black box for 3D as WebGL on a canvas is. A further issue with this proposal is that it doesn't address another request, which is to integrate HTML content into a true 3D scene (e.g. a div mapped onto a sphere, with operational hit testing etc). * Webkit's implementation of CSS does not remove 3D-ified elements from the document flow, the perspective of that flow is merely changed only for the affected elements. 3D and 2D elements can exist side-by-side that way as well. Simon
