Re: [whatwg] Clarification for window.opener.location.href
Yeah, that works well if you're dealing with bleeding-edge browsers only. Not so much elsewhere. :-/ Unfortunately, this isn't a case where progressive enhancement is a suitable approach to dealing with such a security issue. -N On 1/6/2015 12:16 PM, Boris Zbarsky wrote: On 1/6/15 3:10 PM, Nicholas C. Zakas wrote: Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. Not if you use rel=nofollow, per spec. Browser support there is still spotty but improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris -- ___ Nicholas C. Zakas http://www.nczonline.net
Re: [whatwg] Clarification for window.opener.location.href
On 1/5/2015 5:07 PM, Boris Zbarsky wrote: On 1/5/15 5:17 PM, Nicholas C. Zakas wrote: Am I just missing something? Sorry, you're totally right. I was going off the comment in the Chrome bug. If B _isn't_ a toplevel browsing context, then we'd still skip step 1 because A is not sandboxed... This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link So where in this process is the popup window opened? Is that done under the control of the file containing a link to an attacker's page or of the UGC site? Because the current spec mitigation for the problem you describe is that when a site opens a popup it can set its .opener to null to prevent it reaching back into the site that opened it, precisely because of the issue you described. Yes, if we do it with window.open(), then it's possible to set opener to null. However, if you click on a link with target=_blank, window.opener is set as well. This is really the issue. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? As far as I can tell, either you're just misreading the spec or I am. Yup, that's all on me. Thanks for pointing it out. -Boris -- ___ Nicholas C. Zakas http://www.nczonline.net
[whatwg] Clarification for window.opener.location.href
Hi, This bug has been open for Chromium since last year: https://code.google.com/p/chromium/issues/detail?id=168988 It describes the ability of a popup window or other tab to modify the location of it's window.opener even when the two windows have different domains. Basically window.opener.location.href = whatever works all the time, regardless of origin restrictions, and pretty much works that way across all browsers. This seems to indicate that this behavior isn't allowed: https://html.spec.whatwg.org/#allowed-to-navigate This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link, the attacker page redirects the original window to a page that looks like the UGC site but is actually a phishing site designed to look like it. The user doesn't notice this because focus is on the attacker's page in the new window while the redirect happens. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? -- ___ Nicholas C. Zakas http://www.nczonline.net
Re: [whatwg] A better animation API
I'd like to +1 the suggestion for a continuous animation loop, though if I remember correctly I think the concern about such an API was that it would lead to forgotten animations that would keep going long past they should. I'd much rather have an API to start and stop animations, but I'm not sure if the developer convenience outweighs the potential downside of forgotten, long-running paint requests. -N On 12/10/2011 12:13 AM, Boris Zbarsky wrote: On 12/10/11 3:11 AM, Boris Zbarsky wrote: On 12/10/11 2:55 AM, Robert Eisele wrote: It's certainly also more difficult to implement but asking for every frame to continue has also the disadvantage of beeing as slow as setting up a new timeout for every frame. That's why setInterval surpass setTimeout's performance (okay, at least it should). In theory, yes. One other note. The principal practical difference between setInterval and setTimeout (other than all the pages that setInterval something and then forget to cancel it) is their handling of delays in firing times. With setInterval you can get a more uniformly firing timer, because if one firing gets delayed the next one might compensate. With setTimeout the only way to get that behavior is to manually compensate by comparing the actual firing time to the desired one and adjusting the argument to the next setTimeout call accordingly. With requestAnimationFrame, of course, the firing time thing is a non-issue, because you're not scheduling a callback for a particular time in the first place. -Boris -- ___ Nicholas C. Zakas http://www.nczonline.net
Re: [whatwg] Request: window.postMessage should be async
Communication between two frames now is synchronous, and in my opinion, necessarily so. I believe (and I could be wrong) the intent of postMessage() was to allow similar access between frames of different origins as there is between frames of the same origin. If that's the case, then making postMessage() synchronous makes sense...if you're running into cross-frame communication issues currently, this API doesn't introduce any more issues though it admittedly wouldn't fix any either. The question is: was it really designed to? Again, my belief is that the answer is no. -Nicholas - Original Message From: Peter Kasting [EMAIL PROTECTED] To: Jeff Walden [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Saturday, April 5, 2008 3:51:53 PM Subject: Re: [whatwg] Request: window.postMessage should be async On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden [EMAIL PROTECTED] wrote: Peter Kasting wrote: It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up. So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available. (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?) I don't see why this problem requires a technical solution rather than a social one. (I should have mentioned this in the first message, thanks for prompting me to bring it up now.) So, your solution is, all developers writing postMessage-based APIs have to publish a contract, which is not enforced by any tooling but is merely part of some documentation alongside their API, that says how many stack frames they need? That seems like there are all kinds of risks of forgetting to do it, users ignoring it, etc. Why not just do the right thing naturally under the hood? Technical solutions that prevent misuse are always better than social ones, as you yourself originally argued on the security front. Here's another interesting case: what if my postMessage handler is a middleman that needs to itself postMessage to another target (a third party, or back to the original source)? Now I can't guarantee I have sufficient stack depth even if I care and know what my callee is expecting. And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned. No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks. Again, you're imposing extra effort on a potentially large number of callers, whose authors are at various skill levels, for what appears to me to be little gain. When Yahoo publishes some convenient postMessage()-based functionality, why should I have to understand anything about the requirements it imposes on me? Why can't I treat it as a black box? The same argument goes for running time-- if I don't know how long the callsite might take to execute, the only way I can guarantee responsiveness with a sync API is to do something like use Google Gears to get a WorkerPool object so I can effectively thread my JS, and then make my synchronous call in an async way while simultaneoulsy continuing my other processing. An async API, on the other hand, is significantly less risky because I'm guaranteed that I can't block for arbitrary periods of time no matter what the far side does. In most situations I can think of that use postMessage, it would also fit much more naturally into the code I'd be writing. All that happens is an exception, and you can catch and deal with it in the rare case that it happens. Potentially rare in frequency, assuming you're not running on pocket IE, but not in terms of call site structure when one side or the other is opaque -- callers would _always_ need to catch this exception and do something. If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too. I believe in pocket IE you have a ridiculously small stack depth [12?]. This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway. So, the real world is not a problem because you assume manufacturers are going to change it? What past evidence makes you think this will be true? I agree that probably someday we will be in a world where this is a case, but that day may be many years away. I'm not prepared to ignore that market until it happens to fit my conception of what it ought to be. I don't think we should penalize tomorrow for a limitation of today. What penalty are you imposing on tomorrow by making the API async? It's an easier,
Re: [whatwg] [HTML5] Accessibility question
So given all of this, is it reasonable to expect HTML 5 to provide something for this use case? Perhaps my suggestions of @noview introduces incorrect semantics, perhaps something along the lines of @important to indicate content is important regardless of style (and so screen readers should not ignore it)? -Nicholas - Original Message From: Henri Sivonen [EMAIL PROTECTED] To: Nicholas C.Zakas [EMAIL PROTECTED] Cc: Benjamin Hawkes-Lewis [EMAIL PROTECTED]; whatwg List [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED] Sent: Monday, March 31, 2008 3:46:46 AM Subject: Re: [whatwg] [HTML5] Accessibility question On Mar 31, 2008, at 08:10, Nicholas C. Zakas wrote: @irrelevant is virtually indistinguishable from setting content to display: none. My point in bringing up accessibility with a possible attribute or element is to figure out where the lines between HTML and CSS are, as it appears HTML 5 has muddied the water. As I stated earlier on this list, if something is truly irrelevant, then it's not included in the page. Something that's on the page and hidden is relevant, just perhaps not at the current time, which led to the suggestion on this list to rename the attribute ignore. I agree that the semantic fig leaf is confusing. It means hidden (from all interaction modes). I understand your point about superfluity being defined by the presentation (one could argue the same about relevance...). Aural CSS seemed, at one point, like it would make sense for handling such issues. However, since screen readers read the screen media styles, it doesn't really help. More to the point, it is unreasonable to expect casual authors to supply sensible aural CSS even if it were supported. I still feel like it's a good idea to have an optional attribute on each element that indicates the element's content should not be ignored by screen readers regardless of the style applied. Perhaps this could be better handled by an ARIA role... As currently drafted, ARIA has aria-hidden, which is essentially a less elegant duplicate of HTML5 'irrelevant'. As far as I can tell, ARIA doesn't specify aria-hidden=false as overriding display: none; in accessibility API exposure. (But then in general, ARIA doesn't specify processing requirements in the way we expect from HTML5.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com
Re: [whatwg] [HTML5] Accessibility question
@irrelevant is virtually indistinguishable from setting content to display:
none. My point in bringing up accessibility with a possible attribute or
element is to figure out where the lines between HTML and CSS are, as it
appears HTML 5 has muddied the water. As I stated earlier on this list, if
something is truly irrelevant, then it's not included in the page. Something
that's on the page and hidden is relevant, just perhaps not at the current
time, which led to the suggestion on this list to rename the attribute
ignore.
I understand your point about superfluity being defined by the presentation
(one could argue the same about relevance...). Aural CSS seemed, at one point,
like it would make sense for handling such issues. However, since screen
readers read the screen media styles, it doesn't really help.
I still feel like it's a good idea to have an optional attribute on each
element that indicates the element's content should not be ignored by screen
readers regardless of the style applied. Perhaps this could be better handled
by an ARIA role...
-Nicholas
- Original Message
From: Benjamin Hawkes-Lewis [EMAIL PROTECTED]
To: Nicholas C. Zakas [EMAIL PROTECTED]
Cc: whatwg List [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 12:27:37 PM
Subject: Re: [whatwg] [HTML5] Accessibility question
Nicholas C. Zakas wrote:
The first use case is now handled in HTML 5 via @irrelevant.
I don't think it is, actually:
http://www.w3.org/html/wg/html5/#the-irrelevant
Additional content is not irrelevant; it's helpful sometimes and
superfluous at other times.
The draft spec says User agents should not render elements that have
the irrelevant attribute specified. This is incompatible with what I'm
suggesting, which is that user agents might want to render additional
content when it is helpful and ignore it when it is superfluous.
The intention of the draft seems to be that @irrelevant should be
manipulated by scripting. That too is incompatible with what I'm
suggesting, where UA logic and user actions decide whether to render
additional content or not (a bit like @title).hey
We currently now use display: none or
visibility: hidden to hide content that isn't necessary for users at
that time, which is the same purpose as @irrelevant (from previous
discussions).
Display: none; or visibility: hidden; affect only the suggested
presentation of information; @irrelevant changes the semantics.
It's true that developers sometimes try to use display: none; and
visibility: hidden; like @irrelevant could be used; I think that's
(often) unwise because they are such brittle tweaks in the wrong layer.
I'm very familiar with defining separate CSS classes for moving content
offscreen, and it seems like a big hack to me.
It is very hacky, agreed.
It also seems that this
is a common enough use case that it merits further investigation.
Yep.
Perhaps the greater
question is whether or all showing/hiding of content is really a CSS
issue or if there are some that use cases that do belong in HTML.
Sometimes content's superfluity is itself dependent on the
presentational skin. For example, if CSS radically distinguishes a
navigation area from surrounding content, having a Navigation header
might become superfluous. In such cases, it makes more sense to use the
off-screen hack or some better (future) CSS technique, e.g.:
nav h1:out-of-context {
display: block;
}
But ideally a suggested presentational skin should not be used to try
and designate content to be superflous when its superfluity depends on
browsing context not the skin itself, for example when part of a link's
text is superfluous if you're going through the document in order.
--
Benjamin Hawkes-Lewis
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo!
users and friends.
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
Re: [whatwg] [HTML5] Accessibility question
Apologies for not replying sooner, I've been struck with a bit of the flu. The problem I'm trying to solve is the case where you need descriptive text for screen readers but that text is not necessary for sighted users. For example, our accessibility guidelines at Yahoo! say that every unordered list (ul) should be preceeded by a header that describes its use. The header may say something like Page options or Available styles and we use CSS tricks (text-indent: -1px;) to hide these headings from display while allowing screen readers to read them. To sighted users, the meaning of the list is apparent because they can see the visual treatments we've applied whereas blind users would just hear a list read out of context. Another example is for buttons that make use of sprites. Something is implemented as a link but with a background image that's part of a sprite. The link needs to have descriptive text for screen readers but the text is unnecessary for sighted users as they can see the image. For example: a href=# class=closespanClose/span/a For things like this, I usually end up using the same CSS trick mentioned above to move the Close text out of the way. Just looking at the HTML, it's not apparent that Close is not intended to seen. Whereas the following clears it up: a href=# class=closespan noviewClose/span/a Now I know from looking at the source code that Close is clearly not intended to be seen. -Nicholas - Original Message From: Ian Hickson [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: whatwg List [EMAIL PROTECTED] Sent: Sunday, March 16, 2008 6:36:17 PM Subject: Re: [whatwg] [HTML5] Accessibility question On Sun, 16 Mar 2008, Nicholas C. Zakas wrote: I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Wouldn't hiding content from sighted viewers hurt accessibility for sighted viewers? Could you elaborate more on what problem you are trying to solve? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [whatwg] [HTML5] Accessibility question
I don't think this is a CSS issue, it follows along the lines of noscript for hiding content in some cases or @irrelevant (hopefully renamed to @ignore :) ) hiding content in others. CSS generated content will be displayed on the screen just as regular content is, which is the very problem I'm proposing needs to be solved. -Nicholas - Original Message From: Sam Kuper [EMAIL PROTECTED] To: Ian Hickson [EMAIL PROTECTED] Cc: Nicholas C. Zakas [EMAIL PROTECTED]; whatwg List [EMAIL PROTECTED] Sent: Monday, March 17, 2008 7:19:48 PM Subject: Re: [whatwg] [HTML5] Accessibility question On 17/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: That seems more like a CSS issue. I now think so too. Simon Pieters made the point that CSS3 can solve this problem. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[whatwg] [HTML5] Accessibility question
I know the topic has come up a few times, but I'm still wondering if HTML 5 should provide some sort of logic around content that should not be displayed by browsers but should be read by screen readers. Perhaps a noview boolean attribute on each element could be used to tell UAs not to render the content but to report it to screen readers? Or maybe a noview/ element could be used to surround content that shouldn't be displayed but should be accessible to screen readers? Any thoughts? -Nicholas Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: [whatwg] Thoughts on HTML 5
Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! -Nicholas - Original Message From: Shannon [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 3, 2008 3:40:15 PM Subject: Re: [whatwg] Thoughts on HTML 5 Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris Call it note. It may sound crude but it's hard to mistake its meaning. Shannon Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] Thoughts on HTML 5
Thanks, I'm happy to be here. :)
Thanks for a clear explanation of the irrelevant attribute. If you see the
other thread about this, I think we've all now agreed that the purpose for the
attribute makes sense, but the name is another story. It's difficult to spell
for most people and really gives the wrong impression of the content. The
suggestion was made to rename it ignore, which I think makes more sense.
As there is also another thread going on about section/, I don't want to
repeat all of my comments here, but suffice to say that I don't see why I'd
ever use section/ when I get implicit sections by using hn/ elements.
Writers are used to headings indicating sections, and don't really think of a
section as anything on its own. I can understand the use of article/ as
semantically indicating that the area contains information rather than markup,
but I think section/ is overkill.
I understand your reasoning for the aside/ element, perhaps this is another
element that is suffering from the wrong name. Most of web developers have no
idea what an aside is let alone when to use one. I know that acronym/ was
removed because it confused web developers. Given that this is the same
audience, the ones who couldn't figure out the difference between an acronym
and an abbreviation, do you really think that aside/ will get used? Perhaps
it would better be named callout/?
-Nicholas
- Original Message
From: Smylers [EMAIL PROTECTED]
To: whatwg@lists.whatwg.org
Sent: Friday, February 29, 2008 12:02:24 AM
Subject: Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] writes:
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
I join the mailing list to continue the discussion, so here it is:
Hi there Nicholas. Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.
* the irrelevant attribute ... I can't imagine ever using it.
That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.
Lachlan had commented that irrelevant could be changed dynamically
to indicate parts of an application that may be relevant only during
particular points in time.
For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed. At that point the script that's detected the
error condition can set irrelevant to false on the error message.
I don't see how this is any different from hiding content that isn't
necessary.
It _isn't_ different from that; it's exactly that! It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.
The spec says, When specified on an element, it indicates that the
element is not yet, or is no longer, relevant. User agents should
not render elements that have the irrelevant attribute specified.
If it's not relevant, why is it in the page in the first place?
So that it can become relevant in response to events.
* I'm not sure what the section/ element offers over the div/
element. I thought the purpose of the div/ was to indicate a
section of the page. If there's not a clear distinction between
these elements, I don't see the need for a second one.
div is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how span merely denotes a run of text without giving a
reason.
In HTML 4 it's rare to need to resort to span, because there are many
other elements for denoting a span of text for a particular purpose
(em, cite, dfn, etc).
Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently. section is one of those.
A section is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.
For example consider a webpage with this design:
* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information
In HTML 4 that would likely be marked up with lots of divs (or a
table). HTML 5 has meaningful elements for each of those -- header,
nav, article, and aside.
Further, article can be split into sections. Possibly the sidebar
would have
Re: [whatwg] The div element
Reading your description makes me think that you're more displeased with the hn/ elements than you are happy with the section/ element. I've never had issues promoting headers or moving content around, and I'm not clear that section/ would help in any of these circumstances. Nested sections using different hn/ elements seem more confusing to me than just using the hn/ elements. -Nicholas - Original Message From: Tab Atkins Jr. [EMAIL PROTECTED] To: whatwg List [EMAIL PROTECTED] Sent: Saturday, March 1, 2008 11:33:18 AM Subject: Re: [whatwg] The div element On Fri, Feb 29, 2008 at 10:57 PM, Nicholas C. Zakas [EMAIL PROTECTED] wrote: From this description, it seems like the section/ element has little use. If you're talking about writing articles, most authors consider the start and end of sections as implicitly defined by headings. Making this explicit seems unnecessary so long as headings are still available and used. It's just extra syntax to represent something that is more easily represented without it. -Nicholas Certainly they're defined by headings. The issue is *which* heading. If you move sections around (for example, promoting what was originally a subsection to a full section of an article) you have to manually renumber all of your headings to get the semantics right. This is a ton of meaningless search-and-replace. If you use a site template, you have to constantly remember that your content's most important heading is h3 (or whatever), since the h1 and h2 tags are used in the template. If you are writing blog posts, you have *no idea* what your top-most heading should be. If the post is looked at all by itself, perhaps it gets h1 or h2. If the post is displayed among several others on a page, perhaps it should start with h3 because the higher tags are taken up by category headings separating out the posts. If you are copy-pasting someone else's code into your own (for a blockquote, frex), you have to adjust all the headings, because the original author has no way of knowing what level of heading you're using in the piece you're quoting him in (and obviously has no reason to care). These are just the use-cases that I could come up with off the top of my head. All of these are relatively large inconveniences with the current hn nesting scheme. They are all solved by using section tags, since that 'resets' the hn hierarchy by explicitly sectioning the content. Nobody is being forced to section all their content using sections explicitly. That's why the hn implicit sectioning algorithm exists - it's easier to work with. However, there are many situations when being able to explicitly define sections is a great boon. ~TJ Tab, Never miss a thing. Make Yahoo your homepage. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? -Nicholas - Original Message From: James Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Sent: Friday, February 29, 2008 3:58:25 AM Subject: @Irrelevant [was: Re: [whatwg] Thoughts on HTML 5] [EMAIL PROTECTED] wrote: I would like something to indicate that text should not be rendered by the UA but still remain accessible. Content that should be available to screen readers but not have a visual representation is, in fact, relevant. Indeed, which is why such content would not have @irrelevant set. It is content that should be ignored in all UAs would have @irrelevant set. At the moment AT generally tries to infer semantics from the presentation layer (this is display:none so it must be irrelevant), which is why hacks like the one you describe are needed. The irrelevant attribute allows these semantics to be encoded at the markup layer. The biggest problem I can see with this argument for @irrelevant is that it's not quite clear to how to get from where we are today (AT takes account of CSS CSS display properties rather than markup) to the behavior described above. If rendering display:none content that doesn't have the irrelevant attribute set results in a significantly worse web experience than not doing so then AT vendors will presumably be reluctant change behavior. We probably need some investigation into the effect that this change would have on the user experience for AT users. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
From this thread, it seems like the true purpose of irrelevant is to add to HTML the logical equivalent of display:none in CSS. If that is true, then I'd agree with Jeff that renaming the attribute ignore or omit is a good idea. Can anyone either confirm or deny the purpose of this attribute as the following description: This attribute is used to indicate part of a document whose content is not considered primary to the page. In visual UAs, elements with this attribute are not rendered; in non-visual UAs, elements with this attribute are not read as part of the normal content flow. Thoughts? -Nicholas - Original Message From: Jeff Walden [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: James Graham [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Friday, February 29, 2008 11:41:41 AM Subject: Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5] Nicholas C. Zakas wrote: If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? Unnecessarily suggests a particular medium of display; I suggest the shorter alternatives ignore(d) or omit(ted) if you really want the functionality. The biggest problem with the attribute is the spec doesn't sufficiently clearly describe the motivation for it; I suggest mentioning the preloading of iframes as such an example (they don't load/render if they're display:none, so it's either visibility:hidden (?) or launching the element into outer space offscreen with position/top/left), perhaps in an informative paragraph. Jeff Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
[whatwg] Can dialog/ be renamed?
As discussed earlier this week, the dialog/ element is confusing in that the term dialog in software engineering typically means dialog window. I first thought the element was a way to indicate that a part of the page was used as a dialog rather than part of the normal content flow. I understand the need to disambiguate the use of the dl/ element, keeping it as a definition list, so how about cl/ for a conversation list? -Nicholas Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] The div element
From this description, it seems like the section/ element has little use. If you're talking about writing articles, most authors consider the start and end of sections as implicitly defined by headings. Making this explicit seems unnecessary so long as headings are still available and used. It's just extra syntax to represent something that is more easily represented without it. -Nicholas - Original Message From: Tab Atkins Jr. [EMAIL PROTECTED] To: whatwg List [EMAIL PROTECTED] Sent: Friday, February 29, 2008 10:24:49 AM Subject: Re: [whatwg] The div element On Fri, Feb 29, 2008 at 11:39 AM, Nicholas Zakas [EMAIL PROTECTED] wrote: I don't think it's as clear as you make it out to be. A section and a division. I hate to consult a dictionary on this, but one definition for section is subdivision. The naming alone does not make it clear what the difference is. The nav/, header/, and footer/ elements are pretty clear as to their usage. Some additional language might be good for clarifying. Optionally, got any better suggestions for the element's name? Anne mentioned that section/ interacts with h1/-h6/...how so? In HTML5, the hx hierarchy is explicitly ignored. Instead, they're all treated the same. The actual heading level is determined by section nesting. If section/ is something people believe in, then there really has to be more definition around it and its difference with div/. I know part of HTML 5 is to mitigate the div-itis problem, but without clearer distinctions you'll just end up with a mishmash of section/ and div/ being used interchangeably. Okay, let's make sure it's clear. section has a pretty anemic description in the spec currently. To the best of my knowledge, the basic use case of section is dividing up related content within an article. This is pretty easy to use correctly. Question to others: I think it is somewhat unclear what exactly the correct semantics are for section when it is encountered outside of an article. Since section is the most generic of the sectioning tags, there is a definite risk of it falling into the same hole that div is in. Where exactly should section be used when outside of an article, and when should we just default to the div? ~TJ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
