Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 7:20 PM, Ian Hickson wrote: The main difference was that Chrome and Firefox differ in what input types they support, which affects which they allow to affect the implicit submission thing. Oh, ok. Yeah, that's a bit of a mess... ;) Oh, wow, yeah, the spec was just bogus there, sorry about that. I never got around to updating it to handle the activation behaviour stuff properly after fixing that a few years back. Fixed. Looks good, thanks. -Boris
Re: [whatwg] Proposed addition to Drag and Drop API
@Ryosuke - I do not have a concrete proposal but would be interested in helping to work one out. I had idly considered a content attribute but think that specifying an element (perhaps via a function called setDragElement()) would be a simple implementation. @Daniel - I had thought that was possible but in my testing I was not able to get it to work. I had tried referencing an existing element as well as creating a new element but neither were visible while dragging [in Chrome]. On Friday, June 29, 2012 at 4:30 PM, Daniel Cheng wrote: > Can't you use setDragImage() and pass it the element that holds the post > title? > > Daniel > > > On Fri, Jun 29, 2012 at 4:27 PM, Ryosuke Niwa (mailto:rn...@webkit.org)> wrote: > > On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain > (mailto:a...@alexba.in)> wrote: > > > I would prefer not to visually drag the entire post around (which is what > > > happens if I set draggable to true on the post container). My goal is to > > > set draggable on a container element and only show a small element when > > > the user starts dragging. > > > > Ah, that's an interesting use case. Thanks for clarification. Do you have a > > concrete proposal for this? (e.g. adding new content attribute / element). > > > > - Ryosuke > > >
Re: [whatwg] Proposed addition to Drag and Drop API
Can't you use setDragImage() and pass it the element that holds the post title? Daniel On Fri, Jun 29, 2012 at 4:27 PM, Ryosuke Niwa wrote: > On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain wrote: > >> I would prefer not to visually drag the entire post around (which is what >> happens if I set draggable to true on the post container). My goal is to >> set draggable on a container element and only show a small element when the >> user starts dragging. >> > > Ah, that's an interesting use case. Thanks for clarification. Do you have > a concrete proposal for this? (e.g. adding new content attribute / element). > > - Ryosuke > >
Re: [whatwg] Proposed addition to Drag and Drop API
On Fri, Jun 29, 2012 at 4:24 PM, Alex Bain wrote: > I would prefer not to visually drag the entire post around (which is what > happens if I set draggable to true on the post container). My goal is to > set draggable on a container element and only show a small element when the > user starts dragging. > Ah, that's an interesting use case. Thanks for clarification. Do you have a concrete proposal for this? (e.g. adding new content attribute / element). - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 6:19 PM, Boris Zbarsky wrote: > > In any case, I believe the spec is wrong in one aspect: in the case > > that there is a default button, what needs to happen is a click event > > on that button, not just a triggering of its activation behavior. In > > particular, onclick handlers need to fire and the activation behavior > > should only happen if preventDefault is not called on the event. > > Note that depending on how defines handling of click > events, we may get the right thing happening with it for free. > Unfortunately, I'm failing to find where the spec talks about the actual > behavior of @disabled on submit controls. :( It's a bit of a tortuous route. The definition of says: # The disabled attribute is used to make the control non-interactive and # to prevent its value from being submitted. - http://www.whatwg.org/specs/web-apps/current-work/#the-input-element ...which links to: # A form control is disabled if its disabled attribute is set [...] - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-disabled This is used in the element section: # When an input element is disabled, it is immutable. - http://www.whatwg.org/specs/web-apps/current-work/#concept-input-immutable This is then used in the type=submit definition: # If the element is immutable, it has no activation behavior. - http://www.whatwg.org/specs/web-apps/current-work/#submit-button-state-(type=submit) And now the implicit submission section says: # If the platform supports letting the user submit a form implicitly (for # example, on some platforms hitting the "enter" key while a text field is # focused implicitly submits the form), then doing so for a form whose # default button has a defined activation behavior must cause the user # agent to run synthetic click activation steps on that default button. # # Consequently, if the default button is disabled, the form is not # submitted when such an implicit submission mechanism is used. (A button # has no activation behavior when disabled.) - http://www.whatwg.org/specs/web-apps/current-work/#implicit-submission HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed addition to Drag and Drop API
I would prefer not to visually drag the entire post around (which is what happens if I set draggable to true on the post container). My goal is to set draggable on a container element and only show a small element when the user starts dragging. On Friday, June 29, 2012 at 4:21 PM, Ryosuke Niwa wrote: > On Fri, Jun 29, 2012 at 4:12 PM, Alex Bain (mailto:a...@alexba.in)> wrote: > > I've spent the past few days working with the Drag and Drop API and I'd > > like to propose an addition to the spec to aid developers and designers in > > creating accessible drag interfaces. > > > > **Use case:** > > > > I'm developing an app that allows users to drag pieces of user generated > > content (Posts) from one part of the app to another. A Post is represented > > as a DOM subtree with multiple components - a title, some images, text, and > > so forth. I wanted to create an interaction where the user could click and > > drag anywhere on the Post (large click target for accessibility purposes), > > see a subset of the Post as a drag indicator (the title, for example), and > > then be able to drop that elsewhere in the app. > > You can't use draggable content attribute? > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-draggable-attribute > > - Ryosuke >
Re: [whatwg] Proposed addition to Drag and Drop API
On Fri, Jun 29, 2012 at 4:12 PM, Alex Bain wrote: > I've spent the past few days working with the Drag and Drop API and I'd > like to propose an addition to the spec to aid developers and designers in > creating accessible drag interfaces. > > **Use case:** > > I'm developing an app that allows users to drag pieces of user generated > content (Posts) from one part of the app to another. A Post is represented > as a DOM subtree with multiple components - a title, some images, text, and > so forth. I wanted to create an interaction where the user could click and > drag anywhere on the Post (large click target for accessibility purposes), > see a subset of the Post as a drag indicator (the title, for example), and > then be able to drop that elsewhere in the app. > You can't use draggable content attribute? http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-draggable-attribute - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 5:24 PM, Ian Hickson wrote: > > Let me know if it's not quite right. I wasn't sure exactly what weird > > things to test. I mostly relied on WebKit's (specifically Chrome's) > > behaviour here since they were apparently the ones most recently > > affected by real compat reasons to implement something here so maybe > > they are the closest to what the Web today actually needs (?). > > What were the differences between Chrome and Gecko here, if you recall? > I'm somewhat interested. The main difference was that Chrome and Firefox differ in what input types they support, which affects which they allow to affect the implicit submission thing. > In any case, I believe the spec is wrong in one aspect: in the case that > there is a default button, what needs to happen is a click event on that > button, not just a triggering of its activation behavior. In > particular, onclick handlers need to fire and the activation behavior > should only happen if preventDefault is not called on the event. For > example, this testcase: > > > http://w3.org";> > > > > > should alert and not submit. Yes, I know this is totally screwy. :( Oh, wow, yeah, the spec was just bogus there, sorry about that. I never got around to updating it to handle the activation behaviour stuff properly after fixing that a few years back. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Proposed addition to Drag and Drop API
Hello, I've spent the past few days working with the Drag and Drop API and I'd like to propose an addition to the spec to aid developers and designers in creating accessible drag interfaces. **Use case:** I'm developing an app that allows users to drag pieces of user generated content (Posts) from one part of the app to another. A Post is represented as a DOM subtree with multiple components - a title, some images, text, and so forth. I wanted to create an interaction where the user could click and drag anywhere on the Post (large click target for accessibility purposes), see a subset of the Post as a drag indicator (the title, for example), and then be able to drop that elsewhere in the app. **Existing solutions:** 1) I can define a custom drag image that is shown during drag. 2) I can define a custom canvas element that is shown during drag. 1) In this situation a custom drag image would not solve the problem. I would not be able to predefine images for all possible post titles. I could represent all drag actions with a single image but I believe that providing something contextually relevant (an actual component of the post) would be of benefit to users. 2) The custom canvas element could solve this problem but feels unwieldy. **Proposed solution:** In the scenario above I would prefer to define a custom drag element, set the innerHTML to a component of the Post (title), and then style the element itself in CSS. Thoughts? - Alex
Re: [whatwg] Security Issue- Iframe Sandbox attribute - Clarity of operation
On Tue, 6 Mar 2012, Sethu mathavan wrote: > > My code for iframe is . Expected > working is that scripts in the "xyz.htm" should not be executed. > Normally,it works fine. > > But i was able to alter the sandbox attribute by intercepting and > modifying the the response with a proxy tool as follows: src="xyz.htm" sandbox="allow-same-origin allow-scripts"> Now, browser > allows the script in xyz.htm to get executed and original functionality > is altered. > > The main purpose of implementing the sandbox attribute is to restrict > the contents within the particular frame. But that very purpose is being > compromised. This facilitates the Man-in-the-middle attack. Is this the > intended working of the attribute or is there any modifications planned > for the future? Need more clarification on this. On Tue, 6 Mar 2012, Adam Barth wrote: > > The feature is working as intended. If you can intercept and modify the > enclosing page, why not just insert a script block and XSS it directly? I agree with Adam here. > By the way, you might also be interested in the sandbox CSP directive, > which lets you apply a sandbox policy to a resource regardless of the > context in which it's used: > > http://www.w3.org/TR/CSP/#sandbox Even with this, if you can do a man-in-the-middle attack, it provides with minimal to no protection. If you are concerned with MITM attacks, TLS is the right solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 6:19 PM, Boris Zbarsky wrote: In any case, I believe the spec is wrong in one aspect: in the case that there is a default button, what needs to happen is a click event on that button, not just a triggering of its activation behavior. In particular, onclick handlers need to fire and the activation behavior should only happen if preventDefault is not called on the event. Note that depending on how defines handling of click events, we may get the right thing happening with it for free. Unfortunately, I'm failing to find where the spec talks about the actual behavior of @disabled on submit controls. :( -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 5:24 PM, Ian Hickson wrote: Let me know if it's not quite right. I wasn't sure exactly what weird things to test. I mostly relied on WebKit's (specifically Chrome's) behaviour here since they were apparently the ones most recently affected by real compat reasons to implement something here so maybe they are the closest to what the Web today actually needs (?). What were the differences between Chrome and Gecko here, if you recall? I'm somewhat interested. In any case, I believe the spec is wrong in one aspect: in the case that there is a default button, what needs to happen is a click event on that button, not just a triggering of its activation behavior. In particular, onclick handlers need to fire and the activation behavior should only happen if preventDefault is not called on the event. For example, this testcase: http://w3.org";> should alert and not submit. Yes, I know this is totally screwy. :( -Boris
Re: [whatwg] media attribute behavior, static or dynamic ?
On Fri, 11 May 2012, Simon Pieters wrote: > > I'm still a bit skeptical about the utility of . Maybe it > should be dropped from the spec. > > It is not appropriate for choosing between low resolution and high > resolution, because the environment can change (e.g. the user might > fullscreen the video after it has begun loading, and want high > resolution). Also, bandwidth is not available in MQ, but even if it was, > the user agent is in a better position to determine what is appropriate > than the author. > > It would be better to have a solution where the user agent is informed > about which streams are available and what properties they have, and let > the user and user agent switch streams at will. Maybe this should happen > on the network layer, keeping the same selected URL. I don't disagree. I think the right solution is to move all of this into the network layer, personally. I haven't changed the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media attribute of element, default behavior on getting the property.
On Tue, 8 May 2012, Paul Adenot wrote:
>
> Currently implementing the "media" attribute for the element in
> Gecko, we are not sure on how to interpret the spec when the attribute
> is not set in the HTML source.
>
> Considering this snipped of code :
>
>
>
>
>
> What should document.getElementById("asource").media [1] be ?
>
> The spec [2] currently says :
>
> > The default, if the media attribute is omitted, is "all", meaning that
> > by default the media resource is suitable for all media.
>
> At that point, we understand that if no media attribute is specified,
> the expression [1] should return "all".
No, that sentence doesn't say anything except that "the default" (a
constant value used elsewhere in the spec) is the value "all".
Specifically, this part of the sentence is a definition:
# The default, if the media attribute is omitted, is "all"
...and this part of the sentence is a non-normative statement of fact:
# meaning that by default the media resource is suitable for all media.
The constant part is never used in the specification, so it actually has
no effect on implementations whatsoever. It is, effectively, also a
statement of fact. (It it describing what happens in step 6 of the second
set of steps of step 7 of the " resource selection algorithm", which says:
"If candidate has a media attribute whose value does not match the
environment [...]", where the absence of the media attribute thus causes
the step to be ignored -- meaning it behaves as if it was "all".)
I've tried to make this clearer.
> Then spec then says :
>
> > The IDL attributes src, type, and media must reflect the respective ?
> > content attributes of the same name.
>
> At this point, we understand that [1] should return an empty string, but the
> is matched as if media was "all".
>
> The part of the spec about reflection [3] states :
>
> > If a reflecting IDL attribute is a DOMString attribute but doesn't
> > fall into any of the above categories, then the getting and setting
> > must be done in a transparent, case-preserving manner.
>
> which means that [1] should return an empty string.
Correct.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, 21 Feb 2012, Boris Zbarsky wrote: > On 2/21/12 10:47 PM, Dimitri Glazkov wrote: > > I made WebKit match this behavior a couple of years ago: > > https://bugs.webkit.org/show_bug.cgi?id=9756 > > Ah, interesting. Some of the links in that bug indicate that people are > in fact depending on this behavior I've tried to define this in the spec. It's a bit esoteric, but... Let me know if it's not quite right. I wasn't sure exactly what weird things to test. I mostly relied on WebKit's (specifically Chrome's) behaviour here since they were apparently the ones most recently affected by real compat reasons to implement something here so maybe they are the closest to what the Web today actually needs (?). On Tue, 3 Apr 2012, Boris Zbarsky wrote: > On 4/3/12 5:14 PM, Glenn Maynard wrote: > > Ten years later it's still giving me headaches, when I try to do a > > trivial two-input login form without a browser submit button, and find > > that every obvious way of hiding the submit button breaks implicit > > submit in one browser or another. Do I really need to stick the > > submit button in an overflow: hidden, 0x0 div? I know I found a less > > ugly workaround for this the last time I hit this... > > Well, the fact that display:none makes it not submit is clearly a > browser bug in the browsers it happens in. Indeed. On Tue, 21 Feb 2012, Glenn Maynard wrote: > > I don't think the existence of implicit submit should depend on platform > conventions, though, for interop on forms without visible submit > buttons. The form implicit submit takes is a platform convention, but it > should be required to exist in some form or another. User agents aren't actually required to let users input anything, so it doesn't make much sense to require submission be possible... On Thu, 24 May 2012, Rob Crowther wrote: > On 22/02/12 00:35, Ian Hickson wrote: > > I've changed the spec to be clearer that CSS cannot be taken into > > account when determining the default. The default button is just > > always the first submit button in the form. > > What about the situation where there isn't a button? Implicit > submission still seems to happen on forms which have just a single > element, for example: > > http://www.boogdesign.com/examples/forms2/test-validate-1.html > http://www.boogdesign.com/examples/forms2/test-validate-2.html > > These both trigger the form validation algorithm in Firefox, Opera & > Chrome if you just hit return. This form with two inputs doesn't > trigger implicit submission: > > http://www.boogdesign.com/examples/forms2/test-validate-3.html > > But add a submit button and it does: > > http://www.boogdesign.com/examples/forms2/test-validate-4.html > > Because in 4.10.22.2 everything hinges on the 'default button' this > behaviour doesn't seem to be covered. Is this intentional? I've updated the spec to hopefully better match this, as noted above. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification of window.find()
On Wed, 15 Feb 2012, Tab Atkins Jr. wrote: > On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson wrote: > > So I guess we have to make a decision for the platform here. > > > > Do we want: > > > > - To spec window.find() in all its historical glory, and have it > > implemented everywhere? > > > > - To spec a subset of window.find() that just does the use case described > > above, namely to destructively change the selection to a matching part > > of the DOM so that it can be manipulated by script? > > > > - To spec a new API that just returns matching ranges and then allows > > those ranges to be manipulated like the selection can be today? > > > > - To encourage authors to write a library that does this for them, and > > not bother to provide a dedicated API at all? > > > > Which would implementations that don't do the full window.find() today be > > willing to do? > > As far as I know, we (google) would prefer to do nothing with > window.find(), so we can use it for the Selectors API. No opinion on > whether the functionality is useful under another name. On Wed, 15 Feb 2012, Rick Waldron wrote: > > +1 to TJ's mention of find for use in the Selector API: > > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html On Thu, 16 Feb 2012, Tim Down wrote: > > For what it's worth as author of a small library currently working on > implementing something like this feature, I have no love for > window.find(), even if it were consistently implemented in browsers. I > would prefer the use case I described to be met by a different API, > which would ideally provide node-independent text-based > creation/mutation of Ranges, with features similar to those provided by > Microsoft's TextRange. Given the lack of interest in the feature, I have removed it from the spec and recommend to implementors that they drop support for the API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Character-encoding-related threads
On Tue, 14 Feb 2012, Simon Pieters wrote: > On Mon, 13 Feb 2012 18:22:13 +0100, Ian Hickson wrote: > > > I think this is like saying that requiring is an > > > undue burden on authors... > > > > It is. You may recall we tried really hard to make it shorter. At the > > end of the day, however, "" is the best we could do. > > It is a burden, but it's not significantly difficult or anything. I consider all "boilerplate" to be a significant burden. I think there's a huge win to making it trivial to create a Web page. Anything we require makes it less trivial. Currently you need a DOCTYPE, a character encoding declaration, a title, and some content. I'd love to be in a position where the empty string would be a valid document, personally. > > Hm, that's an interesting point. Can we make a list of features that > > rely on the character encoding and have the spec require an encoding > > if any of those are used? > > > > If the list is long or includes anything that it's unreasonable to > > expect will not be used in most Web pages, then we should remove this > > particular "hole" in the conformance criteria. > > The list may well be longer, I haven't checked, but I don't think that > matters. The resolving URL problem is a bad problem because it means > links will stop working for users that have a different default > encoding, so those users leave and go to a competitor site. The form > problem is a bad problem because it means that the database will be > filled with content using various different encodings with no knowledge > of what is what, so when the author realizes this and "fixes" it by > declaring the encoding, it's already too late, the data is broken and is > very hard to repair. > > Letting authors get themselves in a situation where they have broken > data even though it could have been easily prevented seems more like an > undue burden to me. > > Note that both of these features can be hidden in scripts where > validators currently don't even look, so I think it's not a good idea to > make the requirement conditional on these features. Fair enough. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for HTML5: Motion sensing input device (Kinect, SoftKinetic, Asus Xtion)
One last question, if not too much trouble. Seeing that my proposal has not been completely rejected, could I add this to the Category: Proposals for the Wiki?: http://wiki.whatwg.org/wiki/Category:Proposals What do you think? A greeting. 2012/6/28 Jesús Ruiz García > One problem that I think that can happen is that there are no official > drivers for Linux and MAC. > Microsoft should give a solution to this. Although I found that there is a > project called OpenKinect that seems to have advanced work. > http://openkinect.org/wiki/Main_Page > > However as mentioned, to support Kinect and similar devices should not be a > priority actually. > > A greeting ;) > > 2012/6/27 Silvia Pfeiffer > >> On Wed, Jun 27, 2012 at 1:56 PM, Robert O'Callahan >> wrote: >> > On Tue, Jun 26, 2012 at 8:22 AM, Tab Atkins Jr. > >wrote: >> > >> >> The ability to capture sound and video from the user's devices and >> >> manipulate it in the page is already being exposed by the getUserMedia >> >> function. Theoretically, a Kinect can provide this information. >> >> >> >> More advanced functionality like Kinect's depth information probably >> >> needs more study and experience before we start thinking about adding >> >> it to the language itself. >> >> >> > >> > If we were going to support anything like this, I think the best >> approach >> > would be to have a new track type that getUserMedia can return in a >> > MediaStream, containing depth buffer data. >> >> I agree. >> >> Experimentation with this in a non-live manner is already possible by >> using a @kind="metadata" track and putting the Kinect's depth >> information into a WebVTT file to use in parallel with the video. >> >> WebM has further defined how to encapsulate WebVTT into a WebM text >> track [1], so you could even put this information into a video file. >> I believe the same is possible with MPEG [2]. >> >> The exact format for how the Kinect's depth information is delivered >> as a timed metadata track would need to be specified before it could >> turn into its own @kind track type and deliver it live. >> >> >> Cheers, >> Silvia. >> [1] >> http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm >> [2] http://html5.cablelabs.com/tracks/media-container-mapping.html >> > >
Re: [whatwg] Proposal for HTML5: Virtual Tours
Ok, you are right ^_^ Surely with Canvas (WebGL) can be created perfectly virtuals tours. I'll try to do some testing and I will comment on results. Rik good link ;), but would have to test how it behaves Canvas (WebGL) with "hot spots". That is, for example when you have several rooms to visit: http://www.vitaldent.com/nuestras_clinicas.jsp By the way, what label should be used to indicate this type of media?. Canvas? Thanks group, You are very kind and geniuses. Jesús Ruiz jesusr...@php.net 2012/6/29 Rik Cabanier > The underlying flash implementation doesn't have any specific code for > tours either. Flash offers an interface that allows quick swapping of > bitmaps. Canvas offers similar features so a developers should be able to > implement the same interactive interface and reuse many of the same > programming concepts. > > Try this site: http://www.google.com/nexus/#/galaxy/specs > > Rik > Adobe Systems > > On Mon, Jun 25, 2012 at 9:14 AM, Jesús Ruiz García < > jesusruiz2...@gmail.com> wrote: > >> Hello again to all the group whatwg. >> >> I have a second proposal, which like the first, I do not know if it can be >> useful for inclusion in HTML5. >> >> This time, I want to speak to you of the virtual tours, used by museums, >> clinics, libraries, hotels and a long list of websites. >> >> So far, all the more powerful virtual tours I've seen, are made in Flash. >> Usually, these tours are created with the following applications: >> *Easypano Virtual Tour Software*, *3DVista*, *Flashificator*, *Autopano >> Tour >> * and some others. >> >> An example of Easypano virtual tour: >> http://www.vitaldent.com/nuestras_clinicas.jsp >> >> Other examples using 3DVista: >> http://www.3dvista.com/virtual-tours-samples.htm >> >> I've been reviewing whether some library is being developed to support the >> creation of these applications on HTML5. I found a project called >> Pannellum, which uses WebGL: >> http://www.mpetroff.net/archives/2012/05/28/introducing-pannellum/ >> For now though it works properly on Chrome, but isn't powerful or >> beautiful, as are the tours developed with Flash applications. >> >> My proposal is to give more support to this type of works. We could create >> a new tag called "tour" or something similar. If video and audio have own >> tag, also a tour could be differentiated from the other elements of the >> website. >> >> As I always say in my posts, I apologize if this has already been >> discussed, or this isn't HTML5 philosophy. >> >> A greeting, thanks and pardon for my english. >> >> *Jesús Ruiz* >> jesusr...@php.net >> jesusruiz2...@gmail.com >> > >
Re: [whatwg] Proposal for HTML5: Virtual Tours
The underlying flash implementation doesn't have any specific code for tours either. Flash offers an interface that allows quick swapping of bitmaps. Canvas offers similar features so a developers should be able to implement the same interactive interface and reuse many of the same programming concepts. Try this site: http://www.google.com/nexus/#/galaxy/specs Rik Adobe Systems On Mon, Jun 25, 2012 at 9:14 AM, Jesús Ruiz García wrote: > Hello again to all the group whatwg. > > I have a second proposal, which like the first, I do not know if it can be > useful for inclusion in HTML5. > > This time, I want to speak to you of the virtual tours, used by museums, > clinics, libraries, hotels and a long list of websites. > > So far, all the more powerful virtual tours I've seen, are made in Flash. > Usually, these tours are created with the following applications: > *Easypano Virtual Tour Software*, *3DVista*, *Flashificator*, *Autopano > Tour > * and some others. > > An example of Easypano virtual tour: > http://www.vitaldent.com/nuestras_clinicas.jsp > > Other examples using 3DVista: > http://www.3dvista.com/virtual-tours-samples.htm > > I've been reviewing whether some library is being developed to support the > creation of these applications on HTML5. I found a project called > Pannellum, which uses WebGL: > http://www.mpetroff.net/archives/2012/05/28/introducing-pannellum/ > For now though it works properly on Chrome, but isn't powerful or > beautiful, as are the tours developed with Flash applications. > > My proposal is to give more support to this type of works. We could create > a new tag called "tour" or something similar. If video and audio have own > tag, also a tour could be differentiated from the other elements of the > website. > > As I always say in my posts, I apologize if this has already been > discussed, or this isn't HTML5 philosophy. > > A greeting, thanks and pardon for my english. > > *Jesús Ruiz* > jesusr...@php.net > jesusruiz2...@gmail.com >
Re: [whatwg] "content" element, which we need in our documents
Hi Steve, Thank you. I understand. Regards, Ian 2012/6/29 Steve Faulkner > Hi Ian, > > ARIA fills the gap in HTML with role="main" > http://www.w3.org/TR/wai-aria/roles#main > > I agree that an explicit element would be nice, but the powers that be have > rejected the idea. > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com | www.HTML5accessibility.com | > www.twitter.com/stevefaulkner > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > Web Accessibility Toolbar - > www.paciellogroup.com/resources/wat-ie-about.html >
Re: [whatwg] "content" element, which we need in our documents
Hi Ian, ARIA fills the gap in HTML with role="main" http://www.w3.org/TR/wai-aria/roles#main I agree that an explicit element would be nice, but the powers that be have rejected the idea. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] "content" element, which we need in our documents
"sometimes looks messy" If this is the problem, or at least one of problems, how can a wrapper of all this mess, that is a tag, could solve the problem ? It will just add another node in DOM tree in this case without a real benefit. On Fri, Jun 29, 2012 at 4:03 PM, Ian Yang wrote: > By analyzing the example in HTML5 spec, wrapping all content elements can > make the structure of the document become more organized. After all, > content elements all being at the same level of and is > unreasonable, and sometimes looks messy, especially when there are many > different kinds of content elements (p, figure, pre, a, table, .. etc). > > 2012/6/29 Aurelio De Rosa > > > I agree with Ian about the use of and , the > > specifications are really clear on those elements. The are used to wrap > an > > entire entry, not the "content" (in the meaning Ian stated). > > > > The read question for me is: What is the problem of having the content at > > the same level of and (for example inside an > )? > > > > Can't we treat everything inside an article which is not in or > > is the real "content"? > > > > Best regards > > > > On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang wrote: > > > >> As described in whatwg specs, a , in this context, is a > thematic > >> grouping of content, typically with a heading. > >> > >> As for a , which usually contains its own and > , > >> is used to form an independent content like blog entry, comment, or > >> application. > >> > >> Both section and article elements are not the candidate for containing a > >> website or a blog entry's main content. That obviously is the reason > that > >> the example of the nav in HTML5 spec doesn't use them. > >> > >> Regards, > >> Ian Yang > >> > >> 2012/6/29 Cameron Jones > >> > >> > If the content is a special section within the document you should use > >> > the element which has semantic meaning over . > >> > Alternatively you could use if it's distinct and > >> > self-contained. These two elements serve to disambiguate the abstract > >> > idea of content into something with semantic meaning which can be > >> > instrumented by document consumers. > >> > > >> > cam > >> > > >> > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan > >> > wrote: > >> > > > >> > > > >> > > Ian Yang wrote: > >> > > > >> > >>Hi editors in chief and everyone else, > >> > >> > >> > >>How have you been recently? > >> > >> > >> > >>As many of you may have been aware that there is an important > >> > >>sectioning > >> > >>element we have been short of for a long time: the "content" > element. > >> > >> > >> > >>Remember how we sectioned our documents in those old days? It's the > >> > >>meaningless s. We used them and added id="header", > id="content", > >> > >>id="sidebar", and id="footer" to them. > >> > >> > >> > >>After HTML5 came out, we started to have new and semantic elements > >> like > >> > >>"header", "aside", and "footer" to improve our documents. > >> > >> > >> > >>However, today, we are still using the meaningless for our > >> > >>content. > >> > >> > >> > >>The main content forms an important region. And we often wrap it > with > >> > >>an > >> > >>element. By doing so, we distinguish the region from the header and > >> the > >> > >>footer, and also prevent all of its child elements (block level or > >> > >>inline > >> > >>level) being incorrectly at the same level as the header and the > >> > >>footer. > >> > >> > >> > >>In the first example of the intro section of the nav element in > HTML5 > >> > >>Spec > >> > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) > >> (the > >> > >>page > >> > >>takes a while to be fully loaded), the bottom note states: "Notice > the > >> > >>div > >> > >>elements being used to wrap all the contents of the page other than > >> the > >> > >>header and footer, and all the contents of the blog entry other than > >> > >>its > >> > >>header and footer." > >> > >> > >> > >>This example mentioned above is a typical situation that we need an > >> > >>element > >> > >>for the main content. So instead of keep wrapping our contents with > >> the > >> > >>meaningless , why not let the "content" element join HTML5? > >> > >> > >> > >> > >> > >>Sincerely, > >> > >>Ian Yang > >> > >>Meaningful and semantic HTML lover | Front-end developer > >> > > > >> > > I am pretty sure this was discussed a few months back and the answer > >> was > >> > that everything is content, so no need for a content element. The > >> > >> > and just mark up areas of that content with special meaning, > >> but > >> > its still all the main content. > >> > > > >> > > Thanks, > >> > > Ash > >> > > http://ashleysheridan.co.uk > >> > > >> > > > > > > > > -- > > Aurelio De Rosa > > email: aurelioder...@gmail.com > > email: a.der...@audero.it > > website: www.audero.it > > user group: ug.audero.it > > > > > -- Aurelio De Rosa email: aurelioder...@gmail.com email: a.der...@audero.it website: www.audero.it user group: ug.audero.it
Re: [whatwg] "content" element, which we need in our documents
more organized for who? the author or the consumer? this is author aesthetics. On Fri, Jun 29, 2012 at 3:03 PM, Ian Yang wrote: > By analyzing the example in HTML5 spec, wrapping all content elements can > make the structure of the document become more organized. After all, > content elements all being at the same level of and is > unreasonable, and sometimes looks messy, especially when there are many > different kinds of content elements (p, figure, pre, a, table, .. etc). > > 2012/6/29 Aurelio De Rosa > >> I agree with Ian about the use of and , the >> specifications are really clear on those elements. The are used to wrap an >> entire entry, not the "content" (in the meaning Ian stated). >> >> The read question for me is: What is the problem of having the content at >> the same level of and (for example inside an )? >> >> Can't we treat everything inside an article which is not in or >> is the real "content"? >> >> Best regards >> >> On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang wrote: >> >>> As described in whatwg specs, a , in this context, is a thematic >>> grouping of content, typically with a heading. >>> >>> As for a , which usually contains its own and , >>> is used to form an independent content like blog entry, comment, or >>> application. >>> >>> Both section and article elements are not the candidate for containing a >>> website or a blog entry's main content. That obviously is the reason that >>> the example of the nav in HTML5 spec doesn't use them. >>> >>> Regards, >>> Ian Yang >>> >>> 2012/6/29 Cameron Jones >>> >>> > If the content is a special section within the document you should use >>> > the element which has semantic meaning over . >>> > Alternatively you could use if it's distinct and >>> > self-contained. These two elements serve to disambiguate the abstract >>> > idea of content into something with semantic meaning which can be >>> > instrumented by document consumers. >>> > >>> > cam >>> > >>> > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan >>> > wrote: >>> > > >>> > > >>> > > Ian Yang wrote: >>> > > >>> > >>Hi editors in chief and everyone else, >>> > >> >>> > >>How have you been recently? >>> > >> >>> > >>As many of you may have been aware that there is an important >>> > >>sectioning >>> > >>element we have been short of for a long time: the "content" element. >>> > >> >>> > >>Remember how we sectioned our documents in those old days? It's the >>> > >>meaningless s. We used them and added id="header", id="content", >>> > >>id="sidebar", and id="footer" to them. >>> > >> >>> > >>After HTML5 came out, we started to have new and semantic elements >>> like >>> > >>"header", "aside", and "footer" to improve our documents. >>> > >> >>> > >>However, today, we are still using the meaningless for our >>> > >>content. >>> > >> >>> > >>The main content forms an important region. And we often wrap it with >>> > >>an >>> > >>element. By doing so, we distinguish the region from the header and >>> the >>> > >>footer, and also prevent all of its child elements (block level or >>> > >>inline >>> > >>level) being incorrectly at the same level as the header and the >>> > >>footer. >>> > >> >>> > >>In the first example of the intro section of the nav element in HTML5 >>> > >>Spec >>> > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) >>> (the >>> > >>page >>> > >>takes a while to be fully loaded), the bottom note states: "Notice the >>> > >>div >>> > >>elements being used to wrap all the contents of the page other than >>> the >>> > >>header and footer, and all the contents of the blog entry other than >>> > >>its >>> > >>header and footer." >>> > >> >>> > >>This example mentioned above is a typical situation that we need an >>> > >>element >>> > >>for the main content. So instead of keep wrapping our contents with >>> the >>> > >>meaningless , why not let the "content" element join HTML5? >>> > >> >>> > >> >>> > >>Sincerely, >>> > >>Ian Yang >>> > >>Meaningful and semantic HTML lover | Front-end developer >>> > > >>> > > I am pretty sure this was discussed a few months back and the answer >>> was >>> > that everything is content, so no need for a content element. The >>> >>> > and just mark up areas of that content with special meaning, >>> but >>> > its still all the main content. >>> > > >>> > > Thanks, >>> > > Ash >>> > > http://ashleysheridan.co.uk >>> > >>> >> >> >> >> -- >> Aurelio De Rosa >> email: aurelioder...@gmail.com >> email: a.der...@audero.it >> website: www.audero.it >> user group: ug.audero.it >> >>
Re: [whatwg] "content" element, which we need in our documents
By analyzing the example in HTML5 spec, wrapping all content elements can make the structure of the document become more organized. After all, content elements all being at the same level of and is unreasonable, and sometimes looks messy, especially when there are many different kinds of content elements (p, figure, pre, a, table, .. etc). 2012/6/29 Aurelio De Rosa > I agree with Ian about the use of and , the > specifications are really clear on those elements. The are used to wrap an > entire entry, not the "content" (in the meaning Ian stated). > > The read question for me is: What is the problem of having the content at > the same level of and (for example inside an )? > > Can't we treat everything inside an article which is not in or > is the real "content"? > > Best regards > > On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang wrote: > >> As described in whatwg specs, a , in this context, is a thematic >> grouping of content, typically with a heading. >> >> As for a , which usually contains its own and , >> is used to form an independent content like blog entry, comment, or >> application. >> >> Both section and article elements are not the candidate for containing a >> website or a blog entry's main content. That obviously is the reason that >> the example of the nav in HTML5 spec doesn't use them. >> >> Regards, >> Ian Yang >> >> 2012/6/29 Cameron Jones >> >> > If the content is a special section within the document you should use >> > the element which has semantic meaning over . >> > Alternatively you could use if it's distinct and >> > self-contained. These two elements serve to disambiguate the abstract >> > idea of content into something with semantic meaning which can be >> > instrumented by document consumers. >> > >> > cam >> > >> > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan >> > wrote: >> > > >> > > >> > > Ian Yang wrote: >> > > >> > >>Hi editors in chief and everyone else, >> > >> >> > >>How have you been recently? >> > >> >> > >>As many of you may have been aware that there is an important >> > >>sectioning >> > >>element we have been short of for a long time: the "content" element. >> > >> >> > >>Remember how we sectioned our documents in those old days? It's the >> > >>meaningless s. We used them and added id="header", id="content", >> > >>id="sidebar", and id="footer" to them. >> > >> >> > >>After HTML5 came out, we started to have new and semantic elements >> like >> > >>"header", "aside", and "footer" to improve our documents. >> > >> >> > >>However, today, we are still using the meaningless for our >> > >>content. >> > >> >> > >>The main content forms an important region. And we often wrap it with >> > >>an >> > >>element. By doing so, we distinguish the region from the header and >> the >> > >>footer, and also prevent all of its child elements (block level or >> > >>inline >> > >>level) being incorrectly at the same level as the header and the >> > >>footer. >> > >> >> > >>In the first example of the intro section of the nav element in HTML5 >> > >>Spec >> > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) >> (the >> > >>page >> > >>takes a while to be fully loaded), the bottom note states: "Notice the >> > >>div >> > >>elements being used to wrap all the contents of the page other than >> the >> > >>header and footer, and all the contents of the blog entry other than >> > >>its >> > >>header and footer." >> > >> >> > >>This example mentioned above is a typical situation that we need an >> > >>element >> > >>for the main content. So instead of keep wrapping our contents with >> the >> > >>meaningless , why not let the "content" element join HTML5? >> > >> >> > >> >> > >>Sincerely, >> > >>Ian Yang >> > >>Meaningful and semantic HTML lover | Front-end developer >> > > >> > > I am pretty sure this was discussed a few months back and the answer >> was >> > that everything is content, so no need for a content element. The >> >> > and just mark up areas of that content with special meaning, >> but >> > its still all the main content. >> > > >> > > Thanks, >> > > Ash >> > > http://ashleysheridan.co.uk >> > >> > > > > -- > Aurelio De Rosa > email: aurelioder...@gmail.com > email: a.der...@audero.it > website: www.audero.it > user group: ug.audero.it > >
Re: [whatwg] "content" element, which we need in our documents
So, how do you propose to define what represents? As a container element it is a thematic grouping. This is identical to which is a thematic grouping with hierarchical context. What do you want to be able to do? If it is to simply lookup the "content" of the page as a unique concept, this is defined as an article, which in turn may be nested. You can not get around the implications of compound context, do you seek to restrict to a single instance per document? Are you going to restrict to a single instance per context? Or is it a free element which can be defined anywhere and multiple times? a new element does not offer any benefits over what is currently defined. cam On Fri, Jun 29, 2012 at 2:43 PM, Aurelio De Rosa wrote: > I agree with Ian about the use of and , the > specifications are really clear on those elements. The are used to wrap an > entire entry, not the "content" (in the meaning Ian stated). > > The read question for me is: What is the problem of having the content at > the same level of and (for example inside an )? > > Can't we treat everything inside an article which is not in or > is the real "content"? > > Best regards > > On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang wrote: > >> As described in whatwg specs, a , in this context, is a thematic >> grouping of content, typically with a heading. >> >> As for a , which usually contains its own and , >> is used to form an independent content like blog entry, comment, or >> application. >> >> Both section and article elements are not the candidate for containing a >> website or a blog entry's main content. That obviously is the reason that >> the example of the nav in HTML5 spec doesn't use them. >> >> Regards, >> Ian Yang >> >> 2012/6/29 Cameron Jones >> >> > If the content is a special section within the document you should use >> > the element which has semantic meaning over . >> > Alternatively you could use if it's distinct and >> > self-contained. These two elements serve to disambiguate the abstract >> > idea of content into something with semantic meaning which can be >> > instrumented by document consumers. >> > >> > cam >> > >> > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan >> > wrote: >> > > >> > > >> > > Ian Yang wrote: >> > > >> > >>Hi editors in chief and everyone else, >> > >> >> > >>How have you been recently? >> > >> >> > >>As many of you may have been aware that there is an important >> > >>sectioning >> > >>element we have been short of for a long time: the "content" element. >> > >> >> > >>Remember how we sectioned our documents in those old days? It's the >> > >>meaningless s. We used them and added id="header", id="content", >> > >>id="sidebar", and id="footer" to them. >> > >> >> > >>After HTML5 came out, we started to have new and semantic elements like >> > >>"header", "aside", and "footer" to improve our documents. >> > >> >> > >>However, today, we are still using the meaningless for our >> > >>content. >> > >> >> > >>The main content forms an important region. And we often wrap it with >> > >>an >> > >>element. By doing so, we distinguish the region from the header and the >> > >>footer, and also prevent all of its child elements (block level or >> > >>inline >> > >>level) being incorrectly at the same level as the header and the >> > >>footer. >> > >> >> > >>In the first example of the intro section of the nav element in HTML5 >> > >>Spec >> > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the >> > >>page >> > >>takes a while to be fully loaded), the bottom note states: "Notice the >> > >>div >> > >>elements being used to wrap all the contents of the page other than the >> > >>header and footer, and all the contents of the blog entry other than >> > >>its >> > >>header and footer." >> > >> >> > >>This example mentioned above is a typical situation that we need an >> > >>element >> > >>for the main content. So instead of keep wrapping our contents with the >> > >>meaningless , why not let the "content" element join HTML5? >> > >> >> > >> >> > >>Sincerely, >> > >>Ian Yang >> > >>Meaningful and semantic HTML lover | Front-end developer >> > > >> > > I am pretty sure this was discussed a few months back and the answer >> was >> > that everything is content, so no need for a content element. The >> >> > and just mark up areas of that content with special meaning, but >> > its still all the main content. >> > > >> > > Thanks, >> > > Ash >> > > http://ashleysheridan.co.uk >> > >> > > > > -- > Aurelio De Rosa > email: aurelioder...@gmail.com > email: a.der...@audero.it > website: www.audero.it > user group: ug.audero.it
Re: [whatwg] "content" element, which we need in our documents
I agree with Ian about the use of and , the specifications are really clear on those elements. The are used to wrap an entire entry, not the "content" (in the meaning Ian stated). The read question for me is: What is the problem of having the content at the same level of and (for example inside an )? Can't we treat everything inside an article which is not in or is the real "content"? Best regards On Fri, Jun 29, 2012 at 3:20 PM, Ian Yang wrote: > As described in whatwg specs, a , in this context, is a thematic > grouping of content, typically with a heading. > > As for a , which usually contains its own and , > is used to form an independent content like blog entry, comment, or > application. > > Both section and article elements are not the candidate for containing a > website or a blog entry's main content. That obviously is the reason that > the example of the nav in HTML5 spec doesn't use them. > > Regards, > Ian Yang > > 2012/6/29 Cameron Jones > > > If the content is a special section within the document you should use > > the element which has semantic meaning over . > > Alternatively you could use if it's distinct and > > self-contained. These two elements serve to disambiguate the abstract > > idea of content into something with semantic meaning which can be > > instrumented by document consumers. > > > > cam > > > > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan > > wrote: > > > > > > > > > Ian Yang wrote: > > > > > >>Hi editors in chief and everyone else, > > >> > > >>How have you been recently? > > >> > > >>As many of you may have been aware that there is an important > > >>sectioning > > >>element we have been short of for a long time: the "content" element. > > >> > > >>Remember how we sectioned our documents in those old days? It's the > > >>meaningless s. We used them and added id="header", id="content", > > >>id="sidebar", and id="footer" to them. > > >> > > >>After HTML5 came out, we started to have new and semantic elements like > > >>"header", "aside", and "footer" to improve our documents. > > >> > > >>However, today, we are still using the meaningless for our > > >>content. > > >> > > >>The main content forms an important region. And we often wrap it with > > >>an > > >>element. By doing so, we distinguish the region from the header and the > > >>footer, and also prevent all of its child elements (block level or > > >>inline > > >>level) being incorrectly at the same level as the header and the > > >>footer. > > >> > > >>In the first example of the intro section of the nav element in HTML5 > > >>Spec > > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the > > >>page > > >>takes a while to be fully loaded), the bottom note states: "Notice the > > >>div > > >>elements being used to wrap all the contents of the page other than the > > >>header and footer, and all the contents of the blog entry other than > > >>its > > >>header and footer." > > >> > > >>This example mentioned above is a typical situation that we need an > > >>element > > >>for the main content. So instead of keep wrapping our contents with the > > >>meaningless , why not let the "content" element join HTML5? > > >> > > >> > > >>Sincerely, > > >>Ian Yang > > >>Meaningful and semantic HTML lover | Front-end developer > > > > > > I am pretty sure this was discussed a few months back and the answer > was > > that everything is content, so no need for a content element. The > > > and just mark up areas of that content with special meaning, but > > its still all the main content. > > > > > > Thanks, > > > Ash > > > http://ashleysheridan.co.uk > > > -- Aurelio De Rosa email: aurelioder...@gmail.com email: a.der...@audero.it website: www.audero.it user group: ug.audero.it
Re: [whatwg] "content" element, which we need in our documents
As described in whatwg specs, a , in this context, is a thematic grouping of content, typically with a heading. As for a , which usually contains its own and , is used to form an independent content like blog entry, comment, or application. Both section and article elements are not the candidate for containing a website or a blog entry's main content. That obviously is the reason that the example of the nav in HTML5 spec doesn't use them. Regards, Ian Yang 2012/6/29 Cameron Jones > If the content is a special section within the document you should use > the element which has semantic meaning over . > Alternatively you could use if it's distinct and > self-contained. These two elements serve to disambiguate the abstract > idea of content into something with semantic meaning which can be > instrumented by document consumers. > > cam > > On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan > wrote: > > > > > > Ian Yang wrote: > > > >>Hi editors in chief and everyone else, > >> > >>How have you been recently? > >> > >>As many of you may have been aware that there is an important > >>sectioning > >>element we have been short of for a long time: the "content" element. > >> > >>Remember how we sectioned our documents in those old days? It's the > >>meaningless s. We used them and added id="header", id="content", > >>id="sidebar", and id="footer" to them. > >> > >>After HTML5 came out, we started to have new and semantic elements like > >>"header", "aside", and "footer" to improve our documents. > >> > >>However, today, we are still using the meaningless for our > >>content. > >> > >>The main content forms an important region. And we often wrap it with > >>an > >>element. By doing so, we distinguish the region from the header and the > >>footer, and also prevent all of its child elements (block level or > >>inline > >>level) being incorrectly at the same level as the header and the > >>footer. > >> > >>In the first example of the intro section of the nav element in HTML5 > >>Spec > >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the > >>page > >>takes a while to be fully loaded), the bottom note states: "Notice the > >>div > >>elements being used to wrap all the contents of the page other than the > >>header and footer, and all the contents of the blog entry other than > >>its > >>header and footer." > >> > >>This example mentioned above is a typical situation that we need an > >>element > >>for the main content. So instead of keep wrapping our contents with the > >>meaningless , why not let the "content" element join HTML5? > >> > >> > >>Sincerely, > >>Ian Yang > >>Meaningful and semantic HTML lover | Front-end developer > > > > I am pretty sure this was discussed a few months back and the answer was > that everything is content, so no need for a content element. The > and just mark up areas of that content with special meaning, but > its still all the main content. > > > > Thanks, > > Ash > > http://ashleysheridan.co.uk >
Re: [whatwg] "content" element, which we need in our documents
If the content is a special section within the document you should use the element which has semantic meaning over . Alternatively you could use if it's distinct and self-contained. These two elements serve to disambiguate the abstract idea of content into something with semantic meaning which can be instrumented by document consumers. cam On Fri, Jun 29, 2012 at 12:24 PM, Ashley Sheridan wrote: > > > Ian Yang wrote: > >>Hi editors in chief and everyone else, >> >>How have you been recently? >> >>As many of you may have been aware that there is an important >>sectioning >>element we have been short of for a long time: the "content" element. >> >>Remember how we sectioned our documents in those old days? It's the >>meaningless s. We used them and added id="header", id="content", >>id="sidebar", and id="footer" to them. >> >>After HTML5 came out, we started to have new and semantic elements like >>"header", "aside", and "footer" to improve our documents. >> >>However, today, we are still using the meaningless for our >>content. >> >>The main content forms an important region. And we often wrap it with >>an >>element. By doing so, we distinguish the region from the header and the >>footer, and also prevent all of its child elements (block level or >>inline >>level) being incorrectly at the same level as the header and the >>footer. >> >>In the first example of the intro section of the nav element in HTML5 >>Spec >>( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the >>page >>takes a while to be fully loaded), the bottom note states: "Notice the >>div >>elements being used to wrap all the contents of the page other than the >>header and footer, and all the contents of the blog entry other than >>its >>header and footer." >> >>This example mentioned above is a typical situation that we need an >>element >>for the main content. So instead of keep wrapping our contents with the >>meaningless , why not let the "content" element join HTML5? >> >> >>Sincerely, >>Ian Yang >>Meaningful and semantic HTML lover | Front-end developer > > I am pretty sure this was discussed a few months back and the answer was that > everything is content, so no need for a content element. The and > just mark up areas of that content with special meaning, but its > still all the main content. > > Thanks, > Ash > http://ashleysheridan.co.uk
[whatwg] Using ARIA in HTML - intial draft
I have posted an intial draft of a document I have been working on which attempts to provide practical advice to developers on what ARIA to use in HTML. http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html My intention is to provide a non normative resource that fills in the gaps in the current HTML5/HTML specification and a document that is more readable (i.e. less jargonist) It does deviate from HTML5/HTML in some of its suggestions, these deviations are based on current implementation realities. all feedback welcome -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] "content" element, which we need in our documents
Please note that the example of the nav in HTML5 spec uses to wrap all the contents of the page other than the header and footer. And developers always wrap contents with or . Your website does that, too. If everything is content, then we would have never seen codes mentioned above. Regards, Ian Yang 2012/6/29 Ashley Sheridan > > > Ian Yang wrote: > > >Hi editors in chief and everyone else, > > > >How have you been recently? > > > >As many of you may have been aware that there is an important > >sectioning > >element we have been short of for a long time: the "content" element. > > > >Remember how we sectioned our documents in those old days? It's the > >meaningless s. We used them and added id="header", id="content", > >id="sidebar", and id="footer" to them. > > > >After HTML5 came out, we started to have new and semantic elements like > >"header", "aside", and "footer" to improve our documents. > > > >However, today, we are still using the meaningless for our > >content. > > > >The main content forms an important region. And we often wrap it with > >an > >element. By doing so, we distinguish the region from the header and the > >footer, and also prevent all of its child elements (block level or > >inline > >level) being incorrectly at the same level as the header and the > >footer. > > > >In the first example of the intro section of the nav element in HTML5 > >Spec > >( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the > >page > >takes a while to be fully loaded), the bottom note states: "Notice the > >div > >elements being used to wrap all the contents of the page other than the > >header and footer, and all the contents of the blog entry other than > >its > >header and footer." > > > >This example mentioned above is a typical situation that we need an > >element > >for the main content. So instead of keep wrapping our contents with the > >meaningless , why not let the "content" element join HTML5? > > > > > >Sincerely, > >Ian Yang > >Meaningful and semantic HTML lover | Front-end developer > > I am pretty sure this was discussed a few months back and the answer was > that everything is content, so no need for a content element. The > and just mark up areas of that content with special meaning, but > its still all the main content. > > Thanks, > Ash > http://ashleysheridan.co.uk >
Re: [whatwg] "content" element, which we need in our documents
Ian Yang wrote: >Hi editors in chief and everyone else, > >How have you been recently? > >As many of you may have been aware that there is an important >sectioning >element we have been short of for a long time: the "content" element. > >Remember how we sectioned our documents in those old days? It's the >meaningless s. We used them and added id="header", id="content", >id="sidebar", and id="footer" to them. > >After HTML5 came out, we started to have new and semantic elements like >"header", "aside", and "footer" to improve our documents. > >However, today, we are still using the meaningless for our >content. > >The main content forms an important region. And we often wrap it with >an >element. By doing so, we distinguish the region from the header and the >footer, and also prevent all of its child elements (block level or >inline >level) being incorrectly at the same level as the header and the >footer. > >In the first example of the intro section of the nav element in HTML5 >Spec >( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the >page >takes a while to be fully loaded), the bottom note states: "Notice the >div >elements being used to wrap all the contents of the page other than the >header and footer, and all the contents of the blog entry other than >its >header and footer." > >This example mentioned above is a typical situation that we need an >element >for the main content. So instead of keep wrapping our contents with the >meaningless , why not let the "content" element join HTML5? > > >Sincerely, >Ian Yang >Meaningful and semantic HTML lover | Front-end developer I am pretty sure this was discussed a few months back and the answer was that everything is content, so no need for a content element. The and just mark up areas of that content with special meaning, but its still all the main content. Thanks, Ash http://ashleysheridan.co.uk
[whatwg] "content" element, which we need in our documents
Hi editors in chief and everyone else, How have you been recently? As many of you may have been aware that there is an important sectioning element we have been short of for a long time: the "content" element. Remember how we sectioned our documents in those old days? It's the meaningless s. We used them and added id="header", id="content", id="sidebar", and id="footer" to them. After HTML5 came out, we started to have new and semantic elements like "header", "aside", and "footer" to improve our documents. However, today, we are still using the meaningless for our content. The main content forms an important region. And we often wrap it with an element. By doing so, we distinguish the region from the header and the footer, and also prevent all of its child elements (block level or inline level) being incorrectly at the same level as the header and the footer. In the first example of the intro section of the nav element in HTML5 Spec ( http://dev.w3.org/html5/spec/single-page.html#the-nav-element ) (the page takes a while to be fully loaded), the bottom note states: "Notice the div elements being used to wrap all the contents of the page other than the header and footer, and all the contents of the blog entry other than its header and footer." This example mentioned above is a typical situation that we need an element for the main content. So instead of keep wrapping our contents with the meaningless , why not let the "content" element join HTML5? Sincerely, Ian Yang Meaningful and semantic HTML lover | Front-end developer
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 28, 2012 at 9:00 PM, Charlie Reis wrote: > What's the next step for this proposal? Hixie, does the "_unrelated" > target approach sound good to you at this point? > http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts FWIW, all emails to the list will be read by the editor of the relevant specification and replied to in due course. If there's some kind of hurry, you can ask to prioritize (usually done over IRC/IM). -- http://annevankesteren.nl/
