[whatwg] The target= attribute
Summary: * Added name= to object and iframe as a hook for target=. * Made _blank legal again. Hallvord R M Steen wrote: often a page needs to interact with a plugin and tell it to load another file. Today this is of course done with JavaScript, which is difficult because most plugins have different JS interfaces, and there are also differences between the plugins' ActiveX based interfaces in IE and the NPAPI plugin ones. Hence I thought it would be a great simplification if we could do the following: object type=application/x-shockwave-flash id=myMedia data=init.swf /object a href=animation1.swf target=myMedia load movie 1 /a A compliant UA would detect that the target was a plugin and not a window, and call the plugin's NPP_NewStream method (I think, I don't know NPAPI well at all) to notify it of the new file to load. I think backwards compatibility is pretty good since a non-compliant UA would open a new window for the new file. What do you think of this idea? I think this is an interesting idea, though I don't know how much demand there is for this. I would recommend following this up with the group documenting the NPAPI. On Fri, 2 Mar 2007, Michael Enright wrote: If this is commonly done with just one line of JS then a bot could probably find a significant number of pages with that one-liner in the 'a' element's attributes. By one line, I mean a simple unwrapped property change or invocation of a standard method, not through a wrapper. It would be worth spec'ing in HTML5 if it applies to plugins that don't obey the NPAPI. I'm not sure how we could spec something without referencing the plugin API itself. What woudl it mean? Also it is a little troublesome because the proposal messes with the namespace that the target attribute applies to. Currently there is no reason to worry about a clash between the names of the windows and the ids in the current page. To refine the proposal this potential clash would have to be addressed. Could the target attribute in the example be #myMedia to refer to the id on the current page? In general to change the media on plugin P on window W you write 'target=W#P'? And target=_blank#something has no defined resolution. Yeah, there's no clash the way the spec is defined now. On Sun, 8 Apr 2007, Georges MARZIN wrote: I have a suggestion to submit : Look at this piece of code : !-- look at the sharp in the target property -- a href=inc/foo.frg target=#main_area Click here to dynamicaly load a text/html piece of code into the main_area identified dom node /a !-- somewhere in the same document -- div id=main_area/div The content of inc/foo.frg in not a complete html page but only a well formed xhtml piece of code like : div this content is dynamically loaded into a dom node, like ajax, but with a html extended syntax of the target property. /div - With this extension of the target attribute, it might be possible to make some ajax kind of work without javascript enable. - Second: developers don't need to know anything about xmlHttpRequest. - Third avantage: with this syntaxe, a robot can parse the href content to indexe it. Remember that html purist don't like ajax because it use javascript and is not indexable by robots. It is possible to do the same with the target attribute of form element. So the result of submission will appear in a dom element and not cover the whole page. Why not just use iframe? On Sun, 8 Apr 2007, Kornel Lesinski wrote: IMHO it isn't much better than: a href=inc/foo.frg target=main_area iframe name=main_area/iframe It's still as evil as frames - subpages can't be used as standalone documents (thus bookmarked, returned by search engines, etc), because they lack proper navigation menus and in your example they're not even proper documents. Indeed. I think that much better and more powerful solution are ID overlays. The idea is to merge documents instead of completly including one into another. XUL has something like that: http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays Yes, various suggestions along these lines have been made. I'm thinking maybe the best way forwards is to make the spec support these various proposals, but not implement any particular one proposal. (Similarly, Web Forms 2's repetition model, and HTML5's template model, should both probably be removed in favour of simply a supporting infrastructure that allows them to be implemented by script.) On Sun, 8 Apr 2007, Georges MARZIN wrote: When using iframe, the content is treated like a complete and separate html page. So you have in your document a second page completely different from the main document. So, if you want for this sub-page the same comportment and appearance as the main page, you need to write a complete head section with
Re: [whatwg] ALT and equivalent representation
Shannon wrote: Smylers wrote: What advantage does it have over Simon's proposal? Simon's suggestion has the obvious advantage that it already works with current browsers. Smylers Simon's suggestion is no different from the original proposal, the idea that alt can be optional on some images. I think you've misunderstand Simon's suggestion, which was: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Note /all/ the img elements have alt attributes, the point is the alternative text for the group is expressed by the first alt attribute. It's thus actually the same as the fallback you propose: Fallback for current browsers is something I overlooked but it is easy to do: altgroup id=hippo value=Hippopotamus img src=hippo_head.png altgroup=hippo alt=Hippopotamusimg src=hippo_tail.png altgroup=hippo With the alt simply being overridden by altgroup in a HTML5 browser. -- Benjamin Hawkes-Lewis
Re: [whatwg] ALT and equivalent representation
Benjamin Hawkes-Lewis wrote: I think you've misunderstand Simon's suggestion, which was: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Note /all/ the img elements have alt attributes, the point is the alternative text for the group is expressed by the first alt attribute. It's thus actually the same as the fallback you propose: Not the same thing at all. There is no direct association between the elements so there is no way a validator or browser would know the difference between a missing/empty alt and an optional one - thus making ALL use of alt optional as far as formal validation is concerned. If you are implying a group can be denoted by being at the same block level or in the correct order in the stream (no intervening images) then I doubt that would work in practice. Shannon
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
The point of abbr is to expand the acronym, not to just mark up what is an acryonym or abbreviation. Doesn't this claim that the general information that some text is an abbreviation (w/o an expanded form) is basically useless? And is abbrISS/abbr not more useful since less ambiguous than ISS (same abbreviation) and ISS (German imperative for to eat in capitals), and be it just for AT, pronunciation and a scent of semantics? And why do we need to change what HTML 4 left open anyway in the first place; I'm still not convinced that indicates really /needs/ to be replaced by expands: ABBR: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.). [1] [1] http://www.w3.org/TR/html4/struct/text.html#edef-ABBR -- Jens Meiert http://meiert.com/en/
Re: [whatwg] ALT and equivalent representation
On Mon, 21 Apr 2008 08:48:06 +0200, Shannon [EMAIL PROTECTED] wrote: Benjamin Hawkes-Lewis wrote: I think you've misunderstand Simon's suggestion, which was: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Note /all/ the img elements have alt attributes, the point is the alternative text for the group is expressed by the first alt attribute. It's thus actually the same as the fallback you propose: Not the same thing at all. There is no direct association between the elements so there is no way a validator or browser would know the difference between a missing/empty alt and an optional one - thus making ALL use of alt optional as far as formal validation is concerned. Automated conformance checking of alt is not possible anyway. It needs human investigation with knowledge of the context in which the image in question finds itself. Therefore, extra markup for aiding conformance checking is not helping anyone -- on the contrary it adds more cruft for the person checking for conformance. As for browsers, the goal there is to replace all images with their replacement text, and the result of both the above and your proposal would be: Rating: 3/5 Hence, your extra markup isn't helping browsers either. Moreover, it doesn't degrade nicely with existing UAs unless the author goes an extra mile and add alt to all the images (in which case the extra markup becomes pointless again). -- Simon Pieters Opera Software
Re: [whatwg] ALT and equivalent representation
Shannon wrote: Benjamin Hawkes-Lewis wrote: I think you've misunderstand Simon's suggestion, which was: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Note /all/ the img elements have alt attributes, the point is the alternative text for the group is expressed by the first alt attribute. It's thus actually the same as the fallback you propose: Not the same thing at all. There is no direct association between the elements so there is no way a validator or browser would know the difference between a missing/empty alt and an optional one - thus making ALL use of alt optional as far as formal validation is concerned. If you are implying a group can be denoted by being at the same block level or in the correct order in the stream (no intervening images) then I doubt that would work in practice. In /the fallback you propose/ there is no direct association between the images either. In Simon's example, the first image is given an alt of 3/5. The other images are given an alt of . (I'm not sure how the syntax Simon's using fits into http://www.w3.org/html/wg/html5/#attributes1 , but at any rate he's not omitting alt.) So this is the same as: pRating: img src=1 alt=3/5img src=1 alt=img src=1 alt=img src=0 alt=img src=0 alt=/p In this case non-image-rendering user agents should (and, equally importantly, will) render: Rating: 3/5 or something like: Rating: image 3/5 The information that the images are a group would appear to be of only marginal importance in this particular example. I can think of cases where it might be important however: for example, if a content image like a photo or a diagram were sliced up for some reason and the user wanted to copy it elsewhere. The case of Google's logo, described earlier in the thread, is possibly an example of this. But whether we need a mechanism for denoting differing img elements combine to form a single image is a very different question from whether alt should be optional or required. You seem to be conflating them. -- Benjamin Hawkes-Lewis
Re: [whatwg] ALT and equivalent representation
Shannon writes: Shannon wrote: What about this as a possible solution? img src=part1.png altgroup=rating img src=part2.png altgroup=rating img src=part3.png altgroup=rating altgroup id=rating value=3/5 I don't think this would raise any serious implementation issues as the logic is quite simple; Smylers wrote: What advantage does it have over Simon's proposal? Simon's suggestion has the obvious advantage that it already works with current browsers. Simon's suggestion is no different from the original proposal, the idea that alt can be optional on some images. No, Simon was specifying an alt attribute on each image (see below). Fallback for current browsers is something I overlooked but it is easy to do: altgroup id=hippo value=Hippopotamus img src=hippo_head.png altgroup=hippo alt=Hippopotamus img src=hippo_tail.png altgroup=hippo With the alt simply being overridden by altgroup in a HTML5 browser. That still doesn't entirely work with current browsers, because -- unlike Simon's proposal -- you have no alt atttribute at all on the tail. That will provoke image-less browsers into using heuristics to guess what the most appropriate alternative representation is. Whereas in this case the most appropriate alternative is clearly to have nothing, so the author should unambiguously indicate that with alt=. That's also easy to do; it makes your suggestion be: altgroup id=hippo value=Hippopotamus img src=hippo_head.png altgroup=hippo alt=Hippopotamus img src=hippo_tail.png altgroup=hippo alt= For comparision, here's the mark-up following Simon's suggestion: img src=hippo_head.png alt=Hippopotamus img src=hippo_tail.png alt= Note that your suggestion is a superset of his: in order to get yours to work with existing browsers you have to do all of his anyway! So you are effectively asking an author to firstly do something which works in all known current browsers and _then_ put additional work in doing something which will make _no difference whatsoever_ to how the content is presented in any browser at all. Authors are unlikely to be motivated to do that. Shannon writes: Benjamin Hawkes-Lewis wrote: But whether we need a mechanism for denoting differing img elements combine to form a single image is a very different question from whether alt should be optional or required. You seem to be conflating them. How can img alt or img alt= not be related to making alt optional? Because whether the alt attribute is required in all cases (or only required in those where it's possible to provide a plausible alternative[*0]) the above will be allowed either way. Including an alt attribute and setting it to the empty string (which is what the above does) _is_ including an alt attribute; it's specifically saying that the image doesn't convey anything which isn't already conveyed elsewhere on the page, so for imageless browsing the most appropriate action is to omit it entirely from the content. [*0] Note it isn't 'optional', in the sense that at no point does the author have any option as to whether to include it or not; the spec makes it clear that if the author can provide it then she must. Once alt text becomes optional then it is likely that many designers/templates/wysiwyg applications will simply insert alt= into every image to pass validation without consideration ... But that's what we currently have with HTML 4 validation! alt= is already allowed (and indeed is useful in many circumstances). It is this situation I am trying to avoid. Too late! But it's _also_ what HTML 5 is trying to lessen. One way to improve the situation is for people (and tools) _not_ to unthinkingly insert alt= in situations where that _isn't_ appropriate; where it's impossible to know what appropriate alt text is then it's better to leave it out entirely, so as to distinguish these cases. A valid document should provide valid alt information, not empty ones. The spec goes to some length to list different situations in which images are used and explains why alt= is the right thing for some of those. Please could you elaborate on each of those explaining why the spec is wrong and what would be more appropriate alt text than alt=. Smylers
Re: [whatwg] ALT and equivalent representation
Benjamin Hawkes-Lewis wrote: But whether we need a mechanism for denoting differing img elements combine to form a single image is a very different question from whether alt should be optional or required. You seem to be conflating them. How can img alt or img alt= not be related to making alt optional? Both represent a total lack of information with no explicit relationship to any other element. There is no way a parser can resolve whether this information is supplied previously or not. If the parser can't tell then it can't validate the alt requirement - thereby mandating that alt (that is the text, not the empty attribute) be optional for a conforming document (as far as a validator knows anyway). Once alt text becomes optional then it is likely that many designers/templates/wysiwyg applications will simply insert alt= into every image to pass validation without consideration for blind users. It is this situation I am trying to avoid. A valid document should provide valid alt information, not empty ones. An altgroup supports this - empty alt tags do not. Shannon
Re: [whatwg] Footnotes, end notes, side notes
I haven't added any new markup for footnotes or end notes. Side notes without callouts in the main flow are possible with aside. For footnotes and end notes there have been a number of proposals, such as the following (and variants on them): text text footnote note note /footnote text text text text a href=#fn1 target=footnote1/a text text footnote id=fn1 note note /footnote text text a href=#fn1 rel=footnote1/a text text div id=fn1 note note /div text text fn xref=fn1/ text text footnote id=fn1 note note /footnote text text ref to=fn1fallback text text footnote id=fn1 note note /footnote None of these are really compelling, in my opinion. None have the awesome factor that really makes it likely that UAs will ever implement them well. None are especially compellingly better than the currently available options: span title=note notetext tex text text/span ptext text/p aside note note /aside ptext text/p text text a href=#fn1 id=r1 class=footnote1/a text text div id=fn1a href=#r1uarr;/a note note /div I have added a section showing examples of how to use these. Having said that, here are more detailed comments in response to the feedback provided: On Tue, 31 Oct 2006, Michel Fortin wrote: I'm all for a syntax for footnotes (and sidenotes, and endnotes). The question is what do we want a footnote markup to accomplish? Minimally, it should associate a note with its context so that you know there is a note and that you can refer to it if you want. This definition encompass a couple of methods to do such notes that are in use currently, in HTML and elsewhere. 1. One of them, mostly used with sidenotes, is to have the note directly in the text: pSome text span class=sidenotethis is a sidenote to put in the margin/span and some other text./p With pretty trivial CSS, you can then put all the sidenotes in the margin. With some javascript[1], you can also create a list of footnotes at the bottom of the page. This method is also consistent with how word processors treat footnotes: as distinct pieces of text inserted punctually at some place in the main text but which are rendered elsewhere. [1]: http://www.brandspankingnew.net/specials/footnote.html With aside, you can do this, though not directly in a paragraph. If you use more markup, you can make this work today with fallback: pSome text span class=sidenotespan(/spanthis is a sidenote to put in the marginspan)/span/span and some other text./p It might require some tweaking, but you get the idea. 2. Some syntaxes meant to be written directly by humans, like Latex, also allow you to defer the note content until a later time to make things more readable. In these cases, you put a marker in the text, then associate the marker with the note content which can be placed elsewhere in the document. This make the text more readable. My own text-to-HTML tool (PHP Markdown Extra, semi-private beta version 1.1) use such a syntax: Paragraph linked to a footnote[^1]. [^1]: This is the footnote content. Some other paragraph. I'm not aware of anyone doing this for footnotes or sidenotes in HTML; it doesn't seem very practical to style either. You could do this with aside: pParagraph linked to a footnotea href=#fn1 id=r1[1]/a./p aside id=fn1a href=#r1[1]/a: This is the footnote content./aside pSome other paragraph./p 3. The last method of expressing footnotes in HTML is to create markers in the text and put the footnotes in an ordered list at the bottom of the page. For instance, my text-to-HTML tool generates this markup from the above example: pParagraph linked to a footnote supa id=fnref:1 href=#fn:1 rel=footnote1/a/sup. /p pSome other paragraph/p div class=footnotes hr / ol li id=fn:1 pThis is the footnote content. a href=#fnref:1 rev=footnote↩/a /p /li /ol /div This provides a trivial way to style footnotes as footnote, it'll even looks good unstyled and is completely backward compatible. Indeed. (Though I might quibble on the precise structure.) Before defining a markup for footnotes or sidenotes, I think it'd be a good idea to see what goals the syntax should fulfill. Is backward compatibility one of them, or should we always rely on the browser capabilities to relocate footnotes where they should be, or should we allow both? Both seem good. Some other things to take into consideration: * Footnotes should probably not be allowed to escape their enclosing article element. For instance, if you have a couple of weblog articles on your main page, each article having some footnotes, it'd probably not be a good idea to have footnotes from all articles mixed together in the same list. Makes sense. You'd want footnotes scoped to article, and end notes scoped to the
Re: [whatwg] The target= attribute
Ian Hickson wrote: On Sat, 28 Apr 2007, Bill Mason wrote: 3) The back button is not considered reliable as a navigation aid if target=_blank is not in use. Can you elaborate on why this is? I don't particularly believe that this is true. I made that statement in accepting for the sake of argument someone else's assertion from earlier in the thread: [1] Because the Back button is a horribly awkward interface for navigating, especially for getting back to pages you visited a few minutes ago. (In some browsers the Back button has a visible associated menu, but it's hard to open -- and it relies on page titles, which readers probably didn't notice when first scanning those pages, again because of poor browser design.) [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011104.html -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
On Mon, Apr 21, 2008 at 4:15 AM, Jens Meiert [EMAIL PROTECTED] wrote: The point of abbr is to expand the acronym, not to just mark up what is an acryonym or abbreviation. Doesn't this claim that the general information that some text is an abbreviation (w/o an expanded form) is basically useless? And is abbrISS/abbr not more useful since less ambiguous than ISS (same abbreviation) and ISS (German imperative for to eat in capitals), and be it just for AT, pronunciation and a scent of semantics? I'd agree that it *is* basically useless. You can infer that something is an acronym from context - that's how we operate when reading anything else, after all! The ambiguity of some acronyms with actual words is, I would think, far less of a problem than the ambiguity of honest-to-god homographs in our natural languages, which we can generally deal with just fine. Plus, who actually wants to mark up every instance of an abbreviation? That's a ton of work for next to no reward, and apparently isn't something that can be automated (since there are conflicts between abbreviations and actual words). Mark it up once to expand it, and if you want to refer to the original abbreviation again, give it an id and link to it. ~TJ
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Jens Meiert writes: The point of abbr is to expand the acronym, not to just mark up what is an acryonym or abbreviation. Doesn't this claim that the general information that some text is an abbreviation (w/o an expanded form) is basically useless? Well it's very close to being useless. In that if browsers don't do anything with some mark-up, there's no point in having it (and indeed no incentive for authors to provide it). The point of annotating an abbreviation with its expansion is not to mark up the abbreviation _per se_; it's to provide browsers with what the expansion is, so that they can display it. Sure, all instances of just using abbreviations _could_ be marked up. Equally we could mark up verbs, proper nouns, words that score over 30 in Scrabble, palindromes, words that can be written upside-down on calculators, words defined in the Oxford English Dictionary ... There's almost no limit to how text could be marked up to have _some_ use in a particular niche. But that isn't what HTML 5 is going to cater for. And is abbrISS/abbr not more useful since less ambiguous than ISS (same abbreviation) and ISS (German imperative for to eat in capitals) Yes, that is potentially ambiguous. But it's the same in books, newspapers, and so on, where it turns out not to be much of a problem. Human beings tend to be pretty good at working things out from context. For example in an article which has previously mentioned the International Space Station (and possibly also put ISS in brackets after it) readers are going to recognize further uses of ISS. Parts of speech also provide a clue (iss being an imperative only makes sense in certain places in a sentence), as does its being in all-caps -- yes, any word _can_ be written in upper-case, but it's unusual to find one in the middle of a sentence; humans are used to it being an indicator of an abbreviation. Further, distinguishing abbreviations from upper-case-words is far from the only ambiguity in writing: * Words are quite capable of being ambiguous on their own, without any abbreviations in the vicinity. For example entrance can be the place where one enters a building, or the action of putting somebody in a trance. * The same abbreviation is often used for different terms (though often in quite distinct fields). Marking something up as being an abbreviation without giving the expansion wouldn't be any use here. Why should HTML 5 bother to solve the very narrow case of disambiguating words from abbreviations, but not solve it more generally to include the other cases? and be it just for AT, (See, you just used AT there! That _could_ be the English word at written in capitals. It _could_ be a reference to automatic transmission. But readers of this list successfully work out what you were referring to; in practice it isn't ambiguous.) What in practice would you expect AT to do with this knowledge? Remember that most abbreviations that aren't being tagged with expansions won't be marked up, so AT is going to have to deal sensibly with that case anyway. pronunciation Human languages already have many quirks of pronunciation. Speaking browsers have to cope with these heuristically, without help from the mark-up indicating how to pronounce, say, entrance. (As is speaking software that reads out, say, e-mails or word processor documents -- text which doesn't have any underlying mark-up.) Also note that an ordinary word such as 'iss' likely shouldn't be in capitals in the HTML source anyway. If the capitals are wanted for emphasis then it should be written emiss/em, with CSS being used to remove the italics and up-case the text. Are mis-pronounced abbreviations really a significant proportion of mis-pronounced words by speaking browsers? and a scent of semantics? And, what would the point of such a scent be? Why would it be more useful than the scent provided by tagging all verbs with verb? Smylers
Re: [whatwg] postMessage() issues
Aaron Boodman wrote: On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: - Processing a reply synchronously is awkward in any case, since you need a callback. I'm not sure I follow this argument, I actually come to the opposite conclusion. Say that a page is communicating with multiple iframes using postMessage, and expect replies from all of them. If postMessage is synchronous it is easy to associate a given reply with a given postMessage call, it's simply the reply you get between the time you make the postMessage call and when it returns. So you could install a generic listener for the message event and let the listener set a global variable. Then you just do a postMessage and pick up the reply from the global variable. If postMessage is asynchronous you need to agree on using some identifier in the messages, or you have to use the pipes mechanism for all communication. Granted, with javascript generators you can almost get the same behavior as for synchronous calling, but that is non-trivial. This is a really good argument. FWIW, I had not considered the case of coordinating between multiple iframes. That does make the async version significantly more complex. IMO, the tradeoff is still worth it, though. And in the future, with something like Hixie's messaging proposal, this problem will go away (because you'll have stateful objects that represent a conversation). That's still somewhat painful when you are sending multiple messages back and forth since you have to stow away state and resume where you were which can be a big hassle. Certainly not impossible to deal with for a developer, but more complicated. So one thing I should note first of all is that the implementation that is currently in the Firefox 3 betas are synchronous. It is unlikely that we can get this changed by final shipping since we are more or less in code freeze already. Of course, we implemented this knowing that it's part of HTML5 which is nowhere near complete, so obviously we were aware that it might change. However it might mean that developers will have to put in workarounds in order to support the FF3 release :( What about if we just left the sync/async-ness unspecified for the first version of postMessage. In practice this means that implementations might be incompatible, but I don't the workarounds are that big a deal. Authors have this problem already today with XHR in certain edge cases (sometimes onreadystatechange is not asynchronous)? In the future, when the messaging proposal evolves, we tighten it down and make it async. I think that's a really bad idea. Async vs. sync has a huge impact on how to use the API, it's very likely that anyone using the API will break if the implementation changes either way on this. So basically there is very little advantage over specifying nothing at all. / Jonas
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Patrick H. Lauke writes: Smylers wrote: Well it's very close to being useless. In that if browsers don't do anything with some mark-up, there's no point in having it (and indeed no incentive for authors to provide it). Assistive technology is certainly a valid use case here. Would it work well enough? Is not being able to distinguish abbreviations from words a significant problem for developers of such software? Yes, that is potentially ambiguous. But it's the same in books, newspapers, and so on, where it turns out not to be much of a problem. But books etc don't have any other way of providing disambiguation/structure. Under that reasoning, you could argue that there's no need for heading elements etc, as simply having text bigger works fine in print, so all we need is a font sizing markup option. Not quite the same, since in order to make the text bigger we obviously need _some_ mark-up (so there's no advantage in it not being meaningful). But here we're discussing having mark-up versus not having any mark-up at all. What in practice would you expect AT to do with this knowledge? Remember that most abbreviations that aren't being tagged with expansions won't be marked up, so AT is going to have to deal sensibly with that case anyway. So you'd prefer hit and miss heuristics over unambiguous interpretation? We're going to have heuristics anyway. Humans can generally distinguish abbreviations from words, so it isn't too far-fetched to expect AI to be able to do likewise. I can see that unambiguous specification is preferable (if it would work). But I don't understand why of all the problems trying to pronounce human languages correctly this particular one is the one that gets additional help from HTML. Smylers
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Ian, I think you have made a mistake. We need to go through this more methodically before making a decision. I hope the following aids matters. First, lets think about who will use abbreviations and why they need them, second, think about where the information could come from. Situations where expansions of abbreviations are needed: 1) People unfamiliar with the topic being discussed. This can happen if you click a link to an anchor half-way down a page and miss the introduction, or you are reading about a topic new to you. It should not be required that the user screw around looking for the acronym with a dotted underline. This would be terrible for users of non- visual UAs or UAs that don't differentiate abbrs from normal text. 2) Documents that exist as both a single page, and as multiple pages (like large web specifications). Should the expansion occur once per file? That would require additionally marking up every abbr at it's first occurrence on a page when splitting the single-page version. 3) Documents that use the same acronym to mean different things in different contexts/sections. For example, take that both abbr title=United States of AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr previously occurred in the document, and you *don't* want, as an author, for every future use of either term to be expanded by default (so will not provide titles for all occurrences). I then jump into the middle of a page from somewhere else and see The USA's fleet of Space Shuttles are refurbished by USA, LLC. and wonder what's going on! There's no way to tell which is which without heuristical analysis of the language, so the UA can't auto-expand based on a single previous occurrence, which I think is the behaviour you were expecting by disallowing abbrs without titles and removing the referencing. 4) Documents where the acronym and an identically spelled word appear. For example your current system would *require ambiguity* in the admittedly somewhat unlikely newspaper headline: h1abbr title=British American RacingBAR/abbr RAISE THE BAR IN FORMULA ONEh1 Is the second BAR an acronym, which is prohibited from being marked up, or not?No way to tell without heuristical analysis of the language. Certainly not something most UAs will be doing, even for English. What hope would Nahuatl have? At least with abbrBAR/abbr you can tell that it *is* an abbreviation, and can go look for the reference. Telling when a word that's not marked up is or isn't an acronym (so deciding if the UA should provide an expansion) is much harder. Ideally users need to have on-demand expansion of any abbreviation they come across, in any situation, regardless of how competent the HTML author was. Erroneous expansion of non-abbreviations that match a previously defined abbreviation is I think the hardest thing to avoid. Where should these expansions come from? The following fallback list seems reasonable: 1) Inline with @title, the way it's currently done. 2) By referencing, either automatically by the UA or explicitly marked up, an expanded occurrence of the acronym. 3) Glossary file in link tag, which the UA can apply if unambiguous or could be referenced by markup. Not currently a feature of any UA. 4) User's application- or system-wide lexicon file, containing terms in that user's field of occupation. On the Mac OS this is located under VoiceOver Utility→Speech→Pronunciation. 5) Lexicon of the synthesiser, if one is being used. You are prohibiting (2) from being used, with the following consequences: a) Documents will either mark up every acronym with an abbr title=… tag—user agents that expand these by default (primarily aural as I understand it) will appear very verbose—or, b) Documents will only mark up the first occurrence. UAs that do not process subsequent occurrences of the abbreviation (currently all of them), will suffer from lack of definitions. c) In documents with the same abbreviation occurring for two different expansions, UAs will have no means of disambiguating without linguistic processing. Using a to achieve referencing is a very bad idea, as it will pepper documents with little blue underlined words and will and up far more distracting than useful to users. Designers will also hate it, so it will end up not being used at all. Lastly, by disallowing the title attribute to be omitted you make things unnecessarily difficult for currently valid HTML4 to migrate to valid HTML5. — Nicholas Shanks. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Nicholas Shanks writes: Ian, I think you have made a mistake. The message of Ian's you replied to covered several different things (as indicated by the subject line) and you didn't quote any of it. Could you be more specific on which bit you consider to be a mistake? We need to go through this more methodically before making a decision. Ian appears to have looked at every mail sent to this (and other) lists on relevant topics, reading and considering each one in order -- you can't get much more methodical than that! Situations where expansions of abbreviations are needed: 1)People unfamiliar with the topic being discussed. Sure. That can also happen with jargon which isn't an abbreviation. This can happen if you click a link to an anchor half-way down a page and miss the introduction, or you are reading about a topic new to you. If you start partway through a document on an unfamiliar subject it shouldn't be surprising if not everything makes immediate sense! Navigating back to the start seems like a reasonable thing to do. It should not be required that the user screw around looking for the acronym with a dotted underline. * Why is this feature needed for abbreviations, but not for other words people may not be familiar with? * The current draft spec doesn't prohibit an author from marking every use of an abbreviation (or the first one in each section, or the first one after each anchor target, or whatever) with its expansion. 2)Documents that exist as both a single page, and as multiple pages (like large web specifications). Should the expansion occur once per file? That would require additionally marking up every abbr at it's first occurrence on a page when splitting the single-page version. Sure. What would you suggest as an alternative? 3)Documents that use the same acronym to mean different things in different contexts/sections. For example, take that both abbr title=United States of AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr previously occurred in the document, A document re-using an abbreviation like that would have to be written carefully to avoid confusing anybody -- such as by providing enough context that it's obvious which is meant or sometimes writing them out in full. ... and you *don't* want, as an author, for every future use of either term to be expanded by default (so will not provide titles for all occurrences). How does that so follow? If you have multiple instances of USA and you want to disambiguate the expansion of each one then surely you'll have to label each one with its expansion. But why would having this information available mean that the abbreviations would be expanded by default? Surely if the author had wanted text to be read as United Space Alliance in full then the author would have written that, and as such by default it should be read as USA. The expansion is there for users who ask for it, but its existence doesn't imply it will always be forced on users. I then jump into the middle of a page from somewhere else and see The USA's fleet of Space Shuttles are refurbished by USA, LLC. and wonder what's going on! There's no way to tell which is which without heuristical analysis of the language, Sure. But from reading that sentence I can tell from the context which one is which. Both USAs should be displayed the same; both should be spoken the same. Why do they need distinguishing? so the UA can't auto-expand based on a single previous occurrence, which I think is the behaviour you were expecting What in the current spec or Ian's mail makes you think that? My reading of it was that nothing happens automatically: if you encounter a term which you don't understand (whether an abbreviation or not) then you navigate back in the document in the hope of finding an explanation of it. by disallowing abbrs without titles and removing the referencing. How would abbrs without titles help in the above situation anyway? If you really feel the USAs need disambiguating what's deficient about puting title attributes with their expansions on each one? 4)Documents where the acronym and an identically spelled word appear. For example your current system would *require ambiguity* in the admittedly somewhat unlikely newspaper headline: h1abbr title=British American RacingBAR/abbr RAISE THE BAR IN FORMULA ONEh1 Is the second BAR an acronym, which is prohibited from being marked up, or not? Firstly there's nothing prohibiting the second one from being marked up. Secondly, again context makes it pretty obvious. And thirdly, the headline should actually be marked up as: h1abbr title=British American RacingBAR/abbr raise the bar in Formula Oneh1 No way to tell without heuristical analysis of the language. Certainly not something most UAs will be doing, even for English. What hope would Nahuatl have? At least with abbrBAR/abbr you
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
Jim Jewett writes: It isn't clear why the validity constraints of abbr need to be tightened. HTML 5 didn't start as HTML 4, so it isn't so much a case of tightening HTML 4 as having to provide a reason to include things into HTML 5 -- including those defined in HTML 4. The use cases are sufficiently obscure that the cost is low, but what is the benefit of this tightening? What are the use-cases, and what do current browsers do with them? If browsers are already doing something useful then it probably makes sense to keep that behaviour. But if these are theoretical things which future browsers could do then a more substantial case has to be made for what would effectively be creating a new feature. Smylers wrote: Sure, all instances of just using abbreviations _could_ be marked up. Equally we could mark up verbs, proper nouns, ... Nicholas Shanks pointed out that the change made this false. You can still mark up verbs, proper nouns, etc, How? We don't have elements for those. You could use class attributes, but browsers wouldn't do anything with that information by default. And if you used class for that, you could just as easily ... but marking up abbr *without* a title is no longer valid. ... use class to mark up instances of abbreviations. Smylers
Re: [whatwg] Feeedback on dfn, abbr, and other elements related to cross-references
On 21/04/2008, Smylers [EMAIL PROTECTED] wrote: Can you link to examples of such webpages, which have abbr elements without title attibutes? What does that mark-up currently achieve? Out of 130K pages from dmoz.org, I see 592 using abbr elements, and 36 of those using it at least once with no title attribute. If anyone cares enough, they could look through the list to see how many are bogus and how many are expecting something useful and what they seem to be expecting. Those 36 pages which used abbr with no title a couple of months ago: http://bundesrecht.juris.de/gsgv_9 http://linuxdidattica.org/ http://markcronan.livejournal.com/33814.html http://observer.guardian.co.uk/politics/story/0,6903,449920,00.html http://outer-court.com/goodies/index.htm http://spazioinwind.libero.it/saf/ http://tubewhore.livejournal.com/ http://www.artofeurope.com/wong/ http://www.beepworld.de/members10/princessa18/ http://www.cs.tut.fi/~jkorpela/latinaohje.html http://www.danscamera.com/ http://www.fwbosheffield.org/ http://www.gnu.org/ http://www.jokan.de/technik-c2.html http://www.mozilla.org/directory/ http://www.mozilla.org/projects/mathml/ http://www.offaly.ie/offalyhome/visitoffaly/Attractions/Family/bog+train.htm http://www.rekordbog.dk/ http://www.seobythesea.com/ http://www.travelphp.com/ http://www.treseta.fi/ http://www.voyager.prima.de/cpp/books1.html http://www.w3.org/TR/XMLHttpRequest/ (plus 5 more on guardian.co.uk, and 8 more on beepworld.de) -- Philip Taylor [EMAIL PROTECTED]
[whatwg] Use-cases for abbr title (was: Re: Feeedback on dfn, abbr, and other elements related to cross-references)
On Mon, 21 Apr 2008 00:26:46 +0200, Ian Hickson [EMAIL PROTECTED] wrote: I've also made the title= attribute on abbr required, [...] There are legitimate reasons to not fill up the title attribute of abbr. Or should abbr be disallowed in these situations? I've disallowed it. What's the point? There's no harm in titleless abbrs. All you're achieving here is annoying authors who use titleless abbr, maybe as a styling hook to achieve small-caps (e.g. http://www.autisticcuckoo.net/archive.php?id=2007/06/13/samurai-attack uses abbrWCAG/abbr). -- Simon Pieters Opera Software
[whatwg] Minor event-source (SSE) modification
We're using SSE as a reliable Server - Browser streaming mechanism where the server maintains a message queue per user connection. The server needs to buffer all messages until it receives an acknowledgment for a given message (ACK). The server sometimes needs to indicate to the Browser that the message queue has become too large and the browser should send an ACK as soon as possible. One way the server can indicate that it needs an ACK is to end the HTTP Response causing the event-source stream to automatically reconnect with the Last-Event-ID header. We call this an in-band ACK, where the server sends a request for ACK by ending the HTTP response (using transfer-encoding chunked and sending the 0 chunk, for instance.) Normally, a message's latency is the time it takes to travel from the server to the browser, or one leg. For in band ACKing, it takes 3 legs to deliver the next message after an ACK request: 1) Server - Browser (end of response), 2) Browser - Server (new request), 3) Server - Browser (next message). A solution to this problem is to make a second concurrent http request that represents the ACK; this we call an out-of-band ACK. Unfortunately, the current Server-sent Events specification provides no way for a user of the event-source API to know the value of the lastEventId, thus making it impossible to send an ACK out-of-band. We have two proposals, either of which can solve this problem. 1) Expose the id attribute on each dispatched event. This allows us to send out-of-band ACKs as required. The downside is that we would need to extend the MessageEvent interface. 2) Expose an add/remove EventListener on the event-source dom element that dispatches whenever the last event id for an event source is changed. The event generated by a change in the last event id would have that id value as an attribute, as well as the href for the event source associated with the id. We prefer the first solution, but any solution would be good. Any suggestions for a better solution? -Michael Carter
