On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: > > * I almost laughed when I saw the irrelevant attribute. First, > because that's a word that web developers throw around a lot and second > because I can't imagine ever using it. 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? Further, do you know how many people will spell > this wrong 100 times before they spell it right? Unless there's a deeper > meaning or requirement behind this attribute, I think it's just a waste > of a section. > > 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. I don't see how this is any different from > hiding content that isn't necessary.
It's not different from hiding content that isn't necessary. That's exactly what it is. It's a way to hide content that isn't currently relevant. On Thu, 28 Feb 2008, James Graham wrote: > > Presumably a non-visual UA could use the irrelevant attribute to > distinguish content that was not relevant at the current time from > content that was merely being hidden from graphical UAs. I seem to > remember (but I am far from being an expert) that currently aural > browsers ignore display:none content and so best-practice for adding > additional text for aural UAs is to use CSS positioning to move it out > of the viewport. @irrelevant seems to provide a way to move away from > this kind of crazy hack. Right. This attribute says "this shouldn't be here at all for now". Whereas in CSS, you're just saying "optionally, remove this". CSS is fundamentally an optional layer, but sometimes the content really shouldn't be visible regardless of the style layer. On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: > > Screen readers currently ignore elements with styles of display:none and > visibility:hidden. In order to hide elements from the screen but allow > screen readers to see them, we typically use tricks such as > text-indent:-10000 and such. Screen readers should be aural browsers and just use media=speech, but that's another story. > 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. It's relevant in that it gives additional information to > non-sighted users that is probably visually indicated to those who can > see. That's a CSS issue. > If accessibility is the point of the "irrelevant" attribute, then it > fails. It isn't. (Well, accessibility is a key aspect of the attribute, but it isn't specifically for accessibility any more than, say, <p> is.) On Fri, 29 Feb 2008, 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"? The "true" purpose is to separate the structure and semantics from the presentation. "Accessibility" (and "Internationalisation" and "Security" and "Performance") isn't a purpose, it's just a design technique. On Mon, 31 Mar 2008, Nicholas C. Zakas wrote: > > 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)? HTML5 already provides a way to hide content from specific media, the "media" attribute on <style> and <link rel=stylesheet>. On Fri, 29 Feb 2008, Nicholas C. Zakas wrote: > > "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." Given the definition of "rendered" in the spec, that's redundant. On Sat, 1 Mar 2008, Jonas Sicking wrote: > > First off 'irrelevant' is pretty hard to spell for non-native english > speakers (go sweden!). > > Second, the elements are in fact relevant to the page since in all > likelihood they will be used later. 'ignore' feels like a better > description since it's weaker. We want to acknowledges the existance of > the element, but tells you to not pay attention to it. On Thu, 6 Mar 2008, Maciej Stachowiak wrote: > > I like ignore and omit as options. irrelevant is indeed awkward to > spell. On Mon, 31 Mar 2008, Henri Sivonen wrote: > > I agree that the semantic fig leaf is confusing. It means "hidden" (from > all interaction modes). I've renamed it "hidden". On Tue, 29 Apr 2008, Mike Wilson wrote: > > If I understand it correctly, the suggested sections and "irrelevant" > attribute would make dialogs work quite like current modal HTML > dialogs from various js libs (the latter making use of backdrops to > hinder access to original page content) as new content from the same > page is swapped into view "in front" of the original content. > The modality comes natural when the original content is swapped out > from view and only the dialog content is accessible. > > Though, I wonder if these two cases are addressed by sections/ > "irrelevant": > > 1. See-through-view modality > Is it possible to "pop a dialog" on top of (while still showing) the > original content, but hindering interaction with it? (much like what > current js libs offer with their dialog classes) That would be a fine way to render content marked with this attribute, sure. > 2. Unload modality > Most modality discussed so far has been about the view modality, ie > disallowing the user from accessing the original page content until > the dialog has been dismissed. Browser modality may also be about > not letting the browser unload/reload the page until a dialog has > been dismissed (eg "do you want to save before closing the window?"). > Is there any way to force a user to respond to a modal dialog > section before unloading the page? No. Use onunload="" and prompt() for this, if you must. > If not, ideally a generic modality feature could be added to assist both > sections and current style HTML dialogs in achieving this unload > modality. Interesting. This might be something to consider in future, once we have more experience with this attribute. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
