Re: [whatwg] De-emphasis
--- Henri Sivonen [EMAIL PROTECTED] wrote: On Feb 9, 2007, at 19:46, Jonathan Worent wrote: There are plenty of elements in the spec right now that aren't likely to be used often, but they're still in the spec because they have merit. Actually, there are elements that don't have much merit (e.g. samp), but trying to pretend that they don't exist and aren't interoperably presented isn't worth the trouble. What I was trying to say is that it will be impossible to predict an elements usage. Using that as a gauge to determine if something will or won't be added to the spec isn't a fair argument. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail
[whatwg] De-emphasis
Here are my thoughts on the subject: Lets not confuse emphasis and importance. Emphasis defines how much something is stressed. We have to remember that importance does not change the meaning of content. Something that is emphasized is stressed more in relation to other things. Something that is de-emphasized is stressed less. Using both is incredibly important to human speech, which is why my original use case was in marking up dialogs. We should not add an attribute to em we should and a new de-emphasis element. I suggest dem. Nesting is already common with current use of em and strong, and the new use of heading. Adding an attribute to do this is a whole new concept and should be avoided. We already have multiple elements that do similar yet opposite things (e.g. ins/del) so adding a de-emphasis to match emphasis is not a new concept. If you don't think multiple elements that do similar thing should be in the spec then change ins/del to edit action=. But that of course give merit to allowing an attribute on em to define the level of stress. The argument that no-one would use it is pointless. There are plenty of elements in the spec right now that aren't likely to be used often, but they're still in the spec because they have merit. As for the default styling: I'd say either opacity or reducing text size for visual browsers. For audio browsers, voice-stress seem like the obvious choice. Thank you for listening. ___ Jonathan Worent ___ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
Re: [whatwg] De-emphasis
--- James Graham [EMAIL PROTECTED] wrote: Jonathan Worent wrote: The argument that no-one would use it is pointless. There are plenty of elements in the spec right now that aren't likely to be used often, but they're still in the spec because they have merit. No, the argument that no one would use it is important. More elements = more complex spec which is harder to implement /and to use/. Making HTML harder to use is a real cost (compare HTML to e.g. Docbook) which needs to be outweighed by a benefit. As far as I can see, no-one has presented a convincing use case for a deemphasis element - certianly the most common argument has been well we have emphasis so obviously we need deemphasis which is a lousy justification. That was brought but a as secondary argument (still a valid point IMHO). My original use case was for transcribing dialog. This was something I was trying to do when I originally purposed it back in Aug. 07. Unless there is some UA feature that would be enabled by such an element, and some evidence that people would use the element in the correct way in sufficient numbers to make the feature useful, the element should not exist. It is true that several existing HTML elements do not meet this criteria; that is IMHO an unfortunate piece of history that we need not replicate. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
Re: [whatwg] De-emphasis
--- Henri Sivonen [EMAIL PROTECTED] wrote: On Feb 9, 2007, at 01:40, David Latapie wrote: small does not convey any semantic meaning. In HTML5, as drafted, it does. Yeah and I think it much more small much more accurately describes small print than de-emphasis. And since IMHO both and needed in html it would seem that de-emphasis needs a new element. I suggest dem __ Jonathan Worent __ -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
Re: [whatwg] The m element
--- Lachlan Hunt [EMAIL PROTECTED] wrote: Leons, you forgot to CC the list. Leons Petrazickis wrote: Lachlan Hunt wrote: m is for highlighting text that is of some interest to the reader, but it does not alter the meaning of the text itself. Would you say that em is semantic and m is presentational, with the difference from span is in default formatting? Or is meaning not quite the right word - is m like a highlighter in revision change tracking, meant to be seen and then discarded? No, m does have semantics. It marks a specific point of interest, as you might do with a highlighter, it just doesn't alter the meaning of the text itself. Isn't this what strong is for? I.E. signifying the contained text is somehow more important than the surrounding text but not changing the meaning. | 3.12.5 paragraph 3: Changing the importance of a | piece of text with the strong element does not change | the meaning of the sentence. m isn't really needed for revision tracking, we have ins and del for that. Though, another use case is that it could be used to mark a section that needs to be reviewed and/or edited later. That could be particularly useful collaborative editing, like in a wiki. That's often what I use the highlighter tool for in MS Word. -- Lachlan Hunt http://lachy.id.au/ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
I can see what everyones reasoning for not requiring the title (I change my vote :) --- Lachlan Hunt [EMAIL PROTECTED] wrote: James Graham wrote: Lachlan Hunt wrote: Abbreviation expansions should only be supplied when they help the reader to understand the content, not just because the word happens to be an abbreviation. I agree, unless using abbr with no title is useful to get the correct rendering of abbreviations in non-visual media. Using abbr without a title would be useful if it automatically referred to a previous instance with the title attribute. e.g. You could mark up the first occurance as like this abbr title=As Far as I KnowAFAIK/abbr Then, later in the document, you could use it without the title attribute abbrAFAIK/abbr and a UA could allow the user to discover the expansion. This idea is already somewhat supported in the current draft, but requires that it references the defining term of a previously marked up dfn, rather than just another occurrence of the same abbreviation. IMHO, that part of the spec needs fixing. Would dfnabbr title=As Far as I KnowAFAIK/abbr/dfn satisfy this? http://www.whatwg.org/specs/web-apps/current-work/#the-dfn http://www.whatwg.org/specs/web-apps/current-work/#the-abbr -- Lachlan Hunt http://lachy.id.au/ Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com)
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
--- Christoph Päper [EMAIL PROTECTED] wrote: First off I think the requirement for a |title| is too strict, because there are time and space saving abbreviations everyone knows -- i.e. either their expansion or their meaning -- that do not need an expansion, e.g. e.g. or AIDS. Therefore the second sentence should use 'may', not 'should'. I disagree. There is never a guarantee that people will know what an abbreviation stands for, I know what AIDS is but not what it stands for. Also accessing the title information is optional. If the user knows what the abbreviation stands for they won't need to access the title information. Maybe there could be a mechanism using |link| to external abbreviation glossaries, which may use |dl| instead of |dfn|. (I have kind of a deja-vu here, like I already proposed that sometime somewhere.) I think your trying to use abbr for definitions, which is not what its for. Its for specifying what the abbreviation represents not what the word means. I actually do like |acronym| and use it for words where a number or uppercase letter appears non-initially (except Scottish names), which get a reduced font size and/or small caps whereas true abbreviations (with periods) just have their inter-word spacing reduced. Everything else abbr title=does notdoesn't/abbr need markup. I digress, the main reason for this e-mail is the question for the recommended usage of |abbr| (in an English text): 1. abbri. e./abbr abbri.e./abbr abbrie./abbr abbrie/abbr (That's out of the scope of the specification of course.) 2. abbri. e./abbr abbr title=id esti. e./abbr This would be correct usage. abbr title=that isi. e./abbr This would not be correct usage because the abbreviation i.e. does not represent that is it means that though. In this case you using is to mark up the definition. 3. abbr ... lang=lai. e./abbr abbr ... lang=eni. e./abbr AFAIK |lang| (and |xml:lang| as well) applies to the textual element content _and_ its attributes' contents, where this is not of a language-neutral type. I don't quite follow you on this one. The language would be the same for both the abbreviation and the words it is abbreviating. If you cannot answer 2. and 3. the definition of |abbr| is broken, but I expect either of these: abbr title=id est lang=lai. e./abbr abbr title=that is lang=eni. e./abbr (or inherited language) This is a more expressive solution, but also harder to implement: link rel=abbr glossary href=abbr.html ... abbri. e./abbr abbr.html: dl didt lang=lai. e./dt dd lang=laid est/ lang=enthat is/dd/di Again you seem to be wanting to use abbr to markup the definition of the abbreviation. #9484;#9472;#9472;#9472;#9472;#9472;#9472; Jonathan Worent #9472;#9472;#9472;#9472;#9472;#9472;#9488; #9492;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; Webmaster #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9496; Access over 1 million songs - Yahoo! Music Unlimited (http://music.yahoo.com/unlimited)
Re: [whatwg] caption (was: How not to fix HTML)
--- Lachlan Hunt [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html Joe Clark has responed. http://lachy.id.au/log/2006/10/fixing-html#comment-713 His comment is copied here for discussion. [snip] caption generically applicable to tables and figures: We can call it legend if you'd like. I think this is a good idea. Caption could be used with just about any embedded content. Taking cues form the label element for forms you could either make the association explicit by wrapping the caption around the element its captioning caption embed ... A funny video of a man being hit in the groin by a football /caption or make the association implicit by using the for attribute embed id=funnyVid ... caption for=funnyVidA funny video of a man being hit in the groin by a football/caption [not that it matters but Football in the Groin is from a Simpsons episode] [snip] -- Lachlan Hunt http://lachy.id.au/ #9484;#9472;#9472;#9472;#9472;#9472;#9472; Jonathan Worent #9472;#9472;#9472;#9472;#9472;#9472;#9488; #9492;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; Webmaster #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9496; __ Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. (http://advision.webevents.yahoo.com/mailbeta)
Re: [whatwg] Footnotes, endnotes, sidenotes
I came across an article by Jesper Tverskov titled The benefits of footnotes in webpages. (http://www.smackthemouse.com/footnotes) It may be of interest. Everyone is raving about the all-new Yahoo! Mail (http://advision.webevents.yahoo.com/mailbeta/)
Re: [whatwg] getElementsByClassName()
There seems to be a question on how confusing a method would be for developers. I went and asked 4 people I know that are just learning Javascript for the first time. For two of them javascript is their first programing language, the other two already know other languages. Given this markup: p class=foo barPara 1/p p class=bar fooPara 2/p p class=foo bazPara 3/p All expected that getElementsByClassName(foo bar); would match foo bar exactly in the class name and only return Para 1. When asked if they would prefer a comma separated list or an array, there were mixed feelings. Three indicated a preference to a comma separated list, the other said he would expect to pass an array. Given this I would suggest not using a space delimited list. _ Jonathan Worent _ Webmaster __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [whatwg] level attribute
--- [EMAIL PROTECTED] wrote: Jonathan Worent said: I have just recently become interested in the work WHATWG is doing. I apologize if something like this has already been suggested. I'd like to suggest adding a level attribute to both em and strong tags. This attribute would be used to set the level of emphasis/importance, rather than by nesting. The level attribute would take a negative integer, to indicate, de-emphasis/less importance, a positive integer, to indicate increasing emphasis/importance, or a 0, to indicate the default. If the default is desired the level attribute could be left off, unless it is nested within an element that has changed the level (though I can't think of any examples where this would be good practice). There would need to be a reasonable limit for the number of levels, both positively and negatively Examples: em level=2I am getting em level=3very/em angry./em This remember me the highlight tag of some markup language. I don't spend every waking moment on the computer, strong level=-1although my wife thinks otherwise/strong. strong level=1This is a bad example of where the strong level=0default level/strong has to be explicit stated./strong I think a level attribute is better than nesting because it allows for reducing the emphasis/importance below normal. Nesting can only increase this. Not necesarily. emlevel-1emlevel-2/em/em em class=demlevel-2em class=demlevel-1/em/em define proper CSS rules for em class=dem And what if the css is ignored? The text gets emphesized instead of de-emphesized, which totally changes the meaning of the text. Using a level attribute make the meaning of the text explicit to the markup. Let me explain that. The fact that some text is given more or less emphesis/importance than other text changes its meaning. That should therefore be conveyed in the html. You can use css to modigy the way is it interpreted, but if the css is ignored the meaning is not changed. but more natural appears to be changing the markup for deemphasizing. ememlevel-2/ememlevel-1/em Can you give an example using proper sentince structure. I think there would be some instances where rearranging the sentince would be better but not in most cases. A use-case where de-emphasis would be needed is in marking up a transcript. (WCAG requires this for accessibility) De-emphasis could be used to indicate that the speaker whispered. A use-case where indicating less importance would be needed would be digression. This is different than aside IMHO. I understand that this is not backwards compatible. But, IMHO, neither is nesting elements. Future browsers already will have to change to understand that nesting em or strong increases emphasis/importance. They could also be changed to understand the level attribute. If this cannot be done then I would suggest as an alternative: Add 2 new elements. One for indicating de-emphasis, One of indicating less importance. I leave the naming of them to you. The advantage of nesting and reason for the new heading model of XHTML2 is in that you do not need be aware of structure at each instant. Absolute levels h1, h2, h3... are to be avoided in next XHTML2. Why would we reintroduce it in em and strong now? I also find problems with CSS and definition of levels. Is level=2 absolute, i.e. independent of position of em, or relative, i.e. level=2 over level=0 defined by container? I'm not totally sure what you mean. strong level=3 should have more importance than strong level=2 no matter the nesting. Of course, it would be bad practice to skip levels. Thank you, Jonathan Juan R. Center for CANONICAL |SCIENCE) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
