Re: [whatwg] Suggest making dt and dd valid in ol
On 20/07/12 10:52 AM, Ian Yang wrote: On Fri, Jul 20, 2012 at 2:02 AM, Alex Bishopalexbis...@gmail.com wrote: On 19/07/2012 08:04, Ian Yang wrote: Since the *optional *use ofli indl could solve many problems, may we haveli being valid indl? Probably not, as it has similar drawbacks as the proposeddi element: http://wiki.whatwg.org/wiki/FAQ#HTML_should_group_.3Cdt.3Es_and_.3Cdd.3Es_together_in_.3Cdi.3Es.21 Thanks. However, the drawbacks mentioned in that document is about the nonexistentdi, not the existentli. Yes, that whole section is misleading, as has been discussed before: - The benefit of di or li is not just styling - There's no indication that a CSS solution will be developed anyway - As you say, none of those reasons apply to li li indl is rendered without problems in IE6+, FF3.6+, Chrome, and Safari. Only in Opera that definition term and the bullet aren't at the same line. Furthermore, browsers need to be compliant with the standards, not the standers need to be compliant with browsers. If the latter were true, we wouldn't have had so many new HTML5 elements to use. Well, the browser vendors need to agree somewhat before the standard becomes a standard. And at the moment there's lots of cool new stuff to implement, as well as many browser discrepancies and *real* bugs to fix, so I think it will be some time before anyone looks at this issue properly. regards, Sean
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:53 PM, Ian Hickson wrote: On Thu, 5 Apr 2012, Sean Hogan wrote: So the ::backdrop could be styled to not cover the whole page? Could it default to a top layer, but optionally be given a z-index? The ::backdrop specifically would just be immediately below its element in the top layer stack, at least as proposed. Could you elaborate on what your use case is for moving it to other layers? (Ideally with examples of dialogs that do this in the wild -- see the wiki page on which we designed thedialog feature -- http://wiki.whatwg.org/wiki/Dialogs -- for the examples that have primarily driven the design so far.) On Thu, 5 Apr 2012, Sean Hogan wrote: So this top layer prevents all user-interaction with the rest of the page? No, that would be inherent in thedialog showModal() behaviour. If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Those sound like non-modal dialogs. Do you have any examples of modal dialogs on the Web that have these behaviours? As above, screenshots and URLs to such examples would be really helpful. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog OR by clicking the contact link again. The page itself is non-interactive. It's just the bottom menu that doesn't lose interactivity, because it has a higher z-index than the backdrop. I suppose another way of achieving this with dialogs would be to make the site menu a dialog that has no backdrop but is always on top. I don't know if that's something worth considering for the spec. Sean
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 3:31 AM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hicksoni...@hixie.ch wrote:
If this works, then I'll use this fordialog.
How does this work for nested browsing contexts? Currently usingiframe
allowfullscreen (not in HTML yet) you can fullscreen elements embedded via
aniframe. Would we then have to push theiframe element on the stack
and make its height and width cover the viewport, and then push the element
in question inside theiframe on the stack, or do we want to deal with
this in another way?
The thinking so far is that we don't do anything special for dialogs.
They don't escape theiriframe, and theiframe doesn't have any
special response to a dialog spawning within it, unlike for
fullscreen.
Which pseudo-classes are we keeping? :fullscreen still seems useful,
:fullscreen-ancestor probably not. What are the new default styles going to
be?
In the www-style thread I gave a proposal for the new styling. I'll
reproduce it here:
:fullscreen {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
:fullscreen::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
background: black;
}
dialog[modal] {
position: center;
}
dialog[modal]::backdrop {
position: fixed;
top: 0; left: 0; right: 0; bottom: 0;
}
So the ::backdrop could be styled to not cover the whole page?
Could it default to a top layer, but optionally be given a z-index?
Sean
Re: [whatwg] Fullscreen changes to support dialog
On 4/04/12 9:14 AM, Ian Hickson wrote: So based on our discussions on IRC and in person earlier today, I think the following additions to the Fullscreen specification would provide the necessary infrastructure to supportdialog: - Add a new stacking layer to the CSS 2.1 Appendix E layering model, after the current layer 10. Let's call this new layer the top layer. This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. An element in this layer is rendered in the CSS model as an atomic unit that is a sibling to the root element; overflow, opacity, masks, clips, etc, of ancestor elements do not affect it. Outlines must be rendered in their non-layer-10 position if they are specified on an element with an ancestor-or-self that is in such a stack. An element in this layer that has an ancestor-or-self that is display:none does not get rendered. The 'position' property for elements in one of these stacks computes to 'absolute', 'fixed', or 'center' if that is its specifed value, and to 'absolute' if the specified value is anything else. The containing block for such an element is the initial containing block, same as for the root element. The static position for left, right, and top are zero, unless overridden by another specification. (Thedialog spec will override the static position for top.) - Define an algorithm to push an element onto the top layer, which adds a given element to this element's browsing context's viewport's stack, if the element is in a document. - Define an algorithm to yank an element from the top layer, which removes the given element from the stack it is in. When an element is removed from a document, it must be yanked from the top layer. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). If this works, then I'll use this fordialog. Cheers, So this top layer prevents all user-interaction with the rest of the page? If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Sean
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote: On Wed, Apr 4, 2012 at 8:51 PM, Sean Hoganshogu...@westnet.com.au wrote: So the ::backdrop could be styled to not cover the whole page? Yes. It's there for convenience only, since people often want an element that does exactly this. If we didn't provide it explicitly, they'd just awkwardly wrap theirdialogs in a background element anyway. Could it default to a top layer, but optionally be given a z-index? Can you describe a use-case for putting the ::backdrop somewhere other than directly underneath the dialog/fullscreen element? So that a menu-bar in the page can still be interacted with. An optional z-index would be easier than calculating backdrop dimensions to not overlap. On Wed, Apr 4, 2012 at 8:58 PM, Sean Hoganshogu...@westnet.com.au wrote: So this top layer prevents all user-interaction with the rest of the page? If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Both of your examples would be done by using elements that are children of thedialog, and perhaps just positioned explicitly somewhere. That doesn't sound like a good solution, but maybe I'm misunderstanding. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog, OR by clicking the contact link again.
Re: [whatwg] Fullscreen changes to support dialog
On 5/04/12 2:39 PM, Tab Atkins Jr. wrote: On Wed, Apr 4, 2012 at 9:33 PM, Sean Hoganshogu...@westnet.com.au wrote: On 5/04/12 2:15 PM, Tab Atkins Jr. wrote: Both of your examples would be done by using elements that are children of thedialog, and perhaps just positioned explicitly somewhere. That doesn't sound like a good solution, but maybe I'm misunderstanding. Look at my blog: http://meekostuff.net/blog/ At the bottom is a simple site menu. If you click on the contact link it pops up a dialog with a backdrop that covers the whole page... except for the site menu. The dialog can be hidden by a close link in the dialog, OR by clicking the contact link again. I'm not 100% certain, but I suspect this isn't doable withdialog modal, because that's not a modal dialog. It's a normal dialog; you just happen to be using a similar visual effect (darkening the rest of the page) as what modal dialogs typically do, presumably so as to focus attention on the dialog. No, it uses a backdrop to cover the content of the page so that it becomes non-interactive. It's just the bottom menu that doesn't lose interactivity, because it has a higher z-index. Will non-modal `dialog` have a backdrop? Sean
Re: [whatwg] di? Please?
On 5/03/12 10:06 AM, Hugh Guiney wrote: On Sun, Mar 4, 2012 at 5:07 PM, Ian Hicksoni...@hixie.ch wrote: Then why issection in the spec? To make it easier to move subsections around without having to change all theh5s toh4s and so forth. That's it? So the fact that it provides explicit grouping and styling are unintentional side-effects? I don't think I've come across a single person or article discussingsection, in the time since its introduction, ever even mention rearranging subsections as a benefit at all, let alone the *primary* benefit. That's not even mentioned in the spec itself… Furthermore, for h*, the spec provides examples of semantically equivalent document structures, one withsections and one without, concluding: Authors might prefer the former style for its terseness, or the latter style for its convenience in the face of heavy editing; which is besty [sic] is purely an issue of preferred authoring style. If the decision to usesection or not is purely an issue of preferred authoring style, what makesdi any different? Why is in inappropriate to have a stopgap grouping element fordl while CSSWG works on a syntax for pseudo-grouping (if they even decide to do so), yet perfectly fine for sectioning content? Is there any downside if the people who want this feature just do it anyway? The only thing I can think of is that those pages can't be claimed to validate. That shouldn't be an issue for personal sites, and if enough people start using this it will eventually be added to the spec. Sean
Re: [whatwg] Document's base URI should use the document's *current* address
On 20/02/12 2:35 PM, Sean Hogan wrote: On 16/02/12 5:03 PM, Justin Lebar wrote: On Wed, Feb 15, 2012 at 5:31 PM, Ian Hicksoni...@hixie.ch wrote: On Wed, 15 Feb 2012, Justin Lebar wrote: - It sets the document's current address to .../page.html#foo. Well, this is pretty bad. document.location is the document's current address [1]. So clicking #foo changed document.location from page2.html to page.html#foo, which I certainly wouldn't expect (and does not match implementations). Seems to me we should change the implementations then. There isn't any fundamental difference between linking to #foo and linking to page.html#foo if the base URL is page.html, as far as I can tell. If the implementations can't change, then I'll change the spec, but it really seems bad to me that relative URLs will break depending on when they are resolved relative to pushState() changes. When I implemented pushState, I explicitly didn't want authors to have to rewrite all their anchor links after they changed the document's current URI. From an author's point of view, there's no such thing as the document's original URI and, unless you're a nerd, you've never heard of the base URI. There's just the document's URI, modified by pushState. From this point of view, I'd say it's less surprising that relative URIs would break when you change directories (hey, you *asked* for it) than that anchor refs would update the browser's address bar and document.location relative to the old URI. I share your perspective, Justin (if I'm interpreting it correctly). snip By the way, this doesn't quite match what is currently implemented in Firefox and Webkit. According to my testing, although the baseURI after pushState() is the same as the documentURI (so far I've tested img, link and a elts) the actual images and stylesheets used for rendering aren't updated by the pushState() - they should be updated if @src, @href is a rel path. If they were updated then the ones relying on rel paths would often break, which I consider a good behavior - an obvious visual cue to the page author, etc that something was implemented wrongly. Sean I've just realized that Firefox's behavior matches the spec for dynamic changes to base URLs, http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls Personally I think that facilitates broken behavior, but it's not significant as the issue of this thread. Sean
Re: [whatwg] Document's base URI should use the document's *current* address
On 16/02/12 5:03 PM, Justin Lebar wrote:
On Wed, Feb 15, 2012 at 5:31 PM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 15 Feb 2012, Justin Lebar wrote:
- It sets the document's current address to .../page.html#foo.
Well, this is pretty bad. document.location is the document's current
address [1]. So clicking #foo changed document.location from page2.html
to page.html#foo, which I certainly wouldn't expect (and does not match
implementations).
Seems to me we should change the implementations then. There isn't any
fundamental difference between linking to #foo and linking to
page.html#foo if the base URL is page.html, as far as I can tell.
If the implementations can't change, then I'll change the spec, but it
really seems bad to me that relative URLs will break depending on when
they are resolved relative to pushState() changes.
When I implemented pushState, I explicitly didn't want authors to have
to rewrite all their anchor links after they changed the document's
current URI.
From an author's point of view, there's no such thing as the
document's original URI and, unless you're a nerd, you've never heard
of the base URI. There's just the document's URI, modified by
pushState.
From this point of view, I'd say it's less surprising that relative
URIs would break when you change directories (hey, you *asked* for it)
than that anchor refs would update the browser's address bar and
document.location relative to the old URI.
I share your perspective, Justin (if I'm interpreting it correctly).
An obvious use-case for pushState() is facilitating an enhanced
user-experience for page navigation within a site. In this case the
process of document updates + pushState({},null, foo/bar.html) should
result in the same DOM as if foo/bar.html was browsed to directly.
For example, imagine a site that has some pages amenable to this usage:
/page1.html
/page2.html
/subdir/page3.html
These contain some page specific content wrapped in some generic page
template.
(I'm assuming that pages amenable to document updates + pushState() have
a lot in common, otherwise why use pushState().)
!DOCTYPE html
head
link rel=stylesheet href=/style.css /
/head
body
pI hope you are not distracted by my enormous banner. You may want to
a href=#contentskip/a directly to the main content of this page. /p
div id=banner
h1
img src=logo.png / My Site
/h1
/div
nav id=nav
a href=page1.htmlPage 1/a
a href=page2.htmlPage 2/a
a href=subdir/page3.htmlPage 3/a
/nav
div id=content
!-- Page specific content here --
/div
/body
/html
The following stylesheets and images are used:
/style.css
/logo.png
If page creation was all performed on the server using this template then...
- /page1.html /page2.html would be okay
- /subdir/page3.html would be broken:
1. img src=logo.png / has a relative path and refs the
non-existant /subdir/logo.png
2. Similarly, a href= with #nav all have rel paths to nowhere
3. Note that the top skip link is OK in all pages
If a pushState() facilitated mechanism was used for navigation
(a naive implementation which just inserts page-specific content inside
div id=content/div)
and navigation started at /page1.html, thence to /page2.html and
/subdir/page3.html,
the images and hyperlinks in /subdir/page3.html would be fine...
except for the top skip link which references the #content anchor.
Obviously this page template needs fixing and for this example, simply
changing rel paths to absolute will be sufficient for both the server
generated and browser updated documents. Except that pushState()
assisted navigation would break the top skip link (assuming the current
SPECIFIED behavior).
For all the issues in this example I think Justin's proposal is
preferable to what is currently specified.
By the way, this doesn't quite match what is currently implemented in
Firefox and Webkit. According to my testing, although the baseURI after
pushState() is the same as the documentURI (so far I've tested img,
link and a elts) the actual images and stylesheets used for
rendering aren't updated by the pushState() - they should be updated if
@src, @href is a rel path. If they were updated then the ones relying on
rel paths would often break, which I consider a good behavior - an
obvious visual cue to the page author, etc that something was
implemented wrongly.
Sean
Re: [whatwg] di? Please?
On 4/02/12 7:22 AM, Ian Hickson wrote:
On Tue, 10 Jan 2012, Hugh Guiney wrote:
As I understand it, the main reason for rejectingdi was that it
solves a problem that is allegedly CSS's job, but as an author who uses
dls quite extensively, adding a grouping element would really make my
life a lot easier.
There are a number of places in HTML where it would be nice to be able to
group things together -- just look at how often people stickdivs in
their pages for no purpose whatsoever other than styling.
This shouldn't be necessary. It's a limitation of CSS.
The right solution is for CSS to provide some pseudo-element or other
mechanism that introduces an anonymous container into the rendering tree
that wraps the elements you want to wrap. For example, with the square
brackets representing the anonymous boxes:
dl
[dtdd]
[dtdd]
/dl
dl::group(dt...dd) { border: solid; }
header
pa href=/Home/a
[
h1The Blog/h1
p class=bylineOur blog away from home
]
p class=copyrightBla bla
/header
header::group(h1...p.byline) { border: solid; }
This isn't a formal proposal, but you get the idea. If we solve this
problem, the need fordi completely goes away, but more importantly, so
does the need for a huge number ofdivs.
Could you provide examples for how this suggestion solves styling
specific name-value groups within the dl, e.g.
dl li.hidden { display: none; }
dl li.closed dd { display: none; }
dl li::even { background-color: #ccc; }
Re: [whatwg] di? Please?
On 10/01/12 6:32 PM, Hugh Guiney wrote:
As I understand it, the main reason for rejectingdi was that it
solves a problem that is allegedly CSS's job, but as an author who
usesdls quite extensively, adding a grouping element would really
make my life a lot easier.
I would prefer li for this role, and IIRC most browsers will parse
this as desired. Unfortunately the li elements by default have a list
marker which requires extra CSS to work-around, e.g.
dl li { list-style-type: none; }
Yes, my most common problem withdls is styling them, but it's
hardly CSS's fault. What kind of styling am I attempting to do?
Mostly, to arrange them in columns.
Another styling use-case is styling specific name-value groups within
the dl, e.g.
dl li.hidden { display: none; }
dl li.closed dd { display: none; }
dl li::even { background-color: #ccc; }
Re: [whatwg] Link.onload; defer on style, depends
Ian Hickson wrote: On Wed, 25 Mar 2009, Sean Hogan wrote: Ian Hickson wrote: On Sun, 15 Mar 2009, Boris Zbarsky wrote: Sean Hogan wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property. At least in Gecko, you can already detect whether the sheet is done loading: if you try to get its cssRules and that throws INVALID_ACCESS_ERR, then it's still loading. (If it throws DOM_SECURITY_ERR then you're not allowed to read the style data; that's why you have to check for the exact type of exception thrown. Though really, if you're loading style sheets cross-site you're in for a world of hurt unless you control both sites.) I haven't added readyState at this time. I am concerned about feature creep here. As for link.onload, link.readyState is implemented in IE since IE6. Same values as document.readyState, etc. Sure, but we only need one way to do this. How do I check if the resource is already loaded? In a cross-browser, cross-site manner?
Re: [whatwg] Link.onload; defer on style, depends
Ian Hickson wrote: On Thu, 30 Apr 2009, Sean Hogan wrote: At least in Gecko, you can already detect whether the sheet is done loading: if you try to get its cssRules and that throws INVALID_ACCESS_ERR, then it's still loading. (If it throws DOM_SECURITY_ERR then you're not allowed to read the style data; that's why you have to check for the exact type of exception thrown. Though really, if you're loading style sheets cross-site you're in for a world of hurt unless you control both sites.) I haven't added readyState at this time. I am concerned about feature creep here. As for link.onload, link.readyState is implemented in IE since IE6. Same values as document.readyState, etc. Sure, but we only need one way to do this. How do I check if the resource is already loaded? In a cross-browser, cross-site manner? Put an onload handler on the element before it loads and make it set a flag you can check later. And what if the link-element is in the HTML text? The only way to guarantee that is to write it as link onload=... / Surely if it is worth adding the onload event it is worth adding readyState or complete property.
Re: [whatwg] Link.onload; defer on style, depends
Ian Hickson wrote: On Sun, 15 Mar 2009, Boris Zbarsky wrote: Sean Hogan wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property. At least in Gecko, you can already detect whether the sheet is done loading: if you try to get its cssRules and that throws INVALID_ACCESS_ERR, then it's still loading. (If it throws DOM_SECURITY_ERR then you're not allowed to read the style data; that's why you have to check for the exact type of exception thrown. Though really, if you're loading style sheets cross-site you're in for a world of hurt unless you control both sites.) I haven't added readyState at this time. I am concerned about feature creep here. As for link.onload, link.readyState is implemented in IE since IE6. Same values as document.readyState, etc.
Re: [whatwg] Link.onload
Greg Houston wrote: This is a request for the link element to be given an onload attribute. And presumably a readyState property.
Re: [whatwg] WebForms2 validity
Ian Hickson wrote:
On Fri, 9 Feb 2007, Sean Hogan wrote:
I might be missing something obvious, but...
When are ValidityState properties updated? And when are CSS pseudo-classes
(:valid, :invalid, :in-range, :out-of-range) updated?
Continually (in particular whenever the constraints or the values change
-- the validity states are defined in terms of those values).
Ok. But what's the use of checkValidity() on form-control-elements?
Isn't it just:
function() {
if (!this.validity.valid) this.dispatchEvent(invalid);
return this.validity.valid;
}
Many textual input form-controls would begin in one or another invalid
state (valueMissing, patternMismatch) however authors would typically
want CSS validity styles to apply only after checkValidity() - either a
manual one or the automatic one performed by form-submission.
Why?
I would probably now agree that the default should be immediate
application of :valid / :invalid styling which can worked-around with
script. The opposing view (what I would have said a year ago) is...
I think that's the way it usually is now. More specifically:
1. It could be confusing to have :invalid styling on form-controls when
the page first loads.
2. It could be distracting for the styling of a form-control to switch
between :valid and :invalid while the user is typing into it.
3. It could be distracting for the :valid and :invalid styles to apply
before the user tries to submit or explicitly requests the data to be
checked.
#2 can be worked around using :focus. I can't see how #1 and #3 can be
worked around without script.
A :validated pseudo-class that applied after checkValidity() is called
or form-submission has been attempted would give some extra flexibility
in the noscript scenario.
Re: [whatwg] Proposal for a link attribute to replace a href
Simon Pieters wrote: On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? Also it would quite likely clash with existing content that expects that those attributes don't exist on e.g. divs. (Opera has had problems with some new DOM attributes in WF2 due to legacy.) One idea is to enable all elements to cross-reference to hyperlink (a or link) elements. This could be achieved with a link attribute that contains the ID of the hyperlink element. The behavior of elements with @link would be UA defined, but could be: onclick: follow the hyperlink on the referenced a or link elemenr oncontextmenu: offer menu options to a) scrollTo the hyperlink element or b) follow the hyperlink. If the link attribute is present but empty then it could be assumed to reference getElementsByTagName(a)[0]. Pros: - don't need to add properties of hyperlink elements to other elements - Javascript implementations for older browsers would be trivial - the link attribute can be used as a styling hook - multiple elements can use the one hyperlink Cons: - won't inherit :visited styles
Re: [whatwg] The iframe element and sandboxing ideas
Ian Hickson wrote: I'm thinking of introducing a new attribute. I haven't worked out what to call it yet, but definitely not src, source, src2, content, value, or data -- maybe html or doc, though neither of those are great. This attribute would take a string which would then be interpreted as the source document markup of an HTML document, much like the above; it would override src= if it was present, allowing src= to be used for legacy UAs: iframe seamless sandbox=allow-scripts allow-forms doc= !DOCTYPE HTML title/title Welcome to my blog! /sandbox a href='#' onclick='alert(document.cookie)'Click here/a /iframe (There are things we can do to make this better, e.g. make the !DOCTYPE HMTL and title/title bits implicit, maybe introducing type= to say whether it's HTML or XML instead of only supporting HTML, maybe saying that if src= and doc= are both specified they must have identical data, etc.) Comments and suggestions on this are welcome. I haven't added it to the spec yet. I do agree that without this or something equivalent that we don't have a solution for sandboxing embedded blog comments yet. I was wondering if you could use the content of the iframe as the source for the iframe document. By my testing (FF2, FF3b, Saf2, Saf3, Opera9.2, IE6) it seems that current browsers ignore content inside an iframe. So this degrades safely for HTML. The content is available with innerHTML on IE6 and textContent on the others except Safari-2. So you could possibly emulate the HTML5 behavior using JS. This idea doesn't adapt so readily to XHTML. In XHTML the iframe content is also parsed as XHTML, but is not displayed. Unfortunately Safari and Opera execute any scripts. You could put the content in a cdata-section, but it feels wrong. Sorry if this has been discussed before - I couldn't find anything when I searched the list.
[whatwg] Styling of datagrid content
How do you define style for datagrids? e.g. - row color - alternating row color - selected row color - initial column widths - fixed column widths
[whatwg] WebForms2 validity
I might be missing something obvious, but...
When are ValidityState properties updated?
And when are CSS pseudo-classes (:valid, :invalid, :in-range,
:out-of-range) updated?
The spec doesn't say, so I tentatively assume they are meant to always
be up-to-date.
Many textual input form-controls would begin in one or another invalid
state (valueMissing, patternMismatch) however authors would typically
want CSS validity styles to apply only after checkValidity() - either a
manual one or the automatic one performed by form-submission.
Of course, one could always dynamically tag form-controls with some
appropriate class (e.g. validated) and hang your styles off that.
input[type=text]:invalid.validated { background-color: red; }
Which wouldn't work when scripting is disabled, but should be sufficient.
Anyway, could you clarify this?
Ta,
SDH
[whatwg] Seeding a form with initial values
Query 1: The way in which a FORM element with @data is seeded seems internally inconsistent: CLEAR REPEAT directives apply to RepetitionBlocks in the whole document. but FIELD directives only apply to elements within the form. I would prefer FIELD directives to apply to the whole document - that seems consistent with current forms which retrieve a whole new page. Although it does allow conflict between @data on different forms. Query 2: The first step in the initialization algorithm (resetting the form) sounds wrong in the context of form submission. I assume the intention is that the reset() method is called, but the documentation says reset to its initial values as specified in the markup. These two are the same when the document is initially loaded, but the form could easily be changed by the time of form submission. I apologize if these issues have already been discussed.
Re: [whatwg] Web Forms 2.0 proposal
I would request a input filter as a regex range eg a-zA-Z0-9 i.e. if the keyCode is NOT within the range then preventDefault(). I imagine that number, date, datetime, etc will be special implementations that filter keyboard input. Why not extend the facility to text, etc? cheers, SDH
