Re: [whatwg] Element-related feedback; attribution element
On Fri, 14 May 2010, Jim Jewett wrote: > >> > >> Evil Lawyer: So, when did you stop beating your wife? > >> Defendant: Never! > >> > >> "Evil Lawyer" and "Defendant" aren't pronounced. Their meanings (and > >> silence) are deduced from English conventions about punctuation. I > >> would prefer a semantic tag. > > > > Why? What problem would a semantic tag solve? The default styling here > > seems to not need any particular element; the above is perfectly > > understandable as is as far as I can tell. > > For written output, yes, the convention works. > > Ideally, a screen reader should *not* read the attribution labels -- but > it should use them to switch voices. You can in theory do that today using classes and Speech CSS. Do people do it? If not, it's not clear that there's enough demand to add this yet. > >> I'm expecting [scripts] to do something like increase the font size > >> or change the background for lines *I* have to memorize for *my* > >> character [based on the semantic marked in the page identifying the > >> character], or for cue lines that I have to recognize. > > > > Are there any examples of this in the wild? Since this is technically > > possible today, if it's a use case important enough that we should > > address it, it should be easy enough to find examples of this. > > > > I'm very reluctant to provide features for hypothetical problems that > > don't stem from a real market need. (If we start solving such > > problems, we would fast find ourselves on the path to feature bloat.) > > I haven't acted much since finding the internet. I have seen plenty of > printed scripts in which this was done manually with a highlighter for > rehearsals. I would expect today's equivalent to be done at time of > printing, rather than by a helpful web site. Highlighting someone's lines can be done using . > So the need is there; the question is whether the need is too > specialized (like the various poetry elements) ... if the only use were > scripts, I would say that it was too specialized, but I would also use > it for photo credits (the italicized captions), etc. Whether that then > makes it too much of a catchall element -- maybe. Credit for a photograph and the name of the speaker in a script seem like wildly different use cases with very little, if any, overlap. I don't think it makes sense to consider them together. > >> I would expect it to be used by some scrapers looking for stock > >> photos. > > > > I'm not sure what you mean. Wouldn't fingerprinting the photos be more > > effective? > > I was thinking of scrapers acting on behalf of a consumer -- collecting > a bunch of photos that you would be allowed to use. This is a mostly solved problem today -- sites like Flickr and Google Image Search provide license filters in their search tools. > Plenty of model and photographer websites are largely devoted to finding > each other; I assume that this is because photographers are looking to > find (and then contact) models with a particular look, while models are > looking to be photographed by photographers skilled in a certain style. > Again, this seems like a fairly specialized need, but I've seen in on > several sites, and it again gets met by an attribution or credits > element. This seems like an incredibly specialised need that is best solved by special-purpose databases and tools than by the Web's markup language. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element-related feedback
On Fri, Jul 23, 2010 at 11:54 AM, Ian Hickson wrote: > Most platforms have built-in mechanisms for showing dates and times in a > fashion of the user's chosing. I suggest using that. It may be that this > ends up being a lost cause, or that authors don't care about this, but I > think we should at least give it a shot. I'm reluctant to have an element > that does nothing visual and is just used for encoding data, since that is > likely to end up with a lot more bogus data than if it actually does > something. Fwiw, as an author, I certainly care about this, and like the ability to localize the display of the datetime. ~TJ
Re: [whatwg] Element-related feedback
On Tue, 16 Mar 2010, Philip Jägenstedt wrote: > On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson wrote: > > On Mon, 16 Nov 2009, Philip Jägenstedt wrote: > > > > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0 > > > > > > "When the time binding applies to a time element, the element is > > > expected to render as if it contained text conveying the date (if > > > known), time (if known), and time-zone offset (if known) represented > > > by the element, in the fashion most convenient for the user." > > > > > > This is very vague. Anything which tries to localize the date/time > > > will fail because guessing the language of web pages is hard. > > > Hard-coding it to English also wouldn't be very nice. What seems to > > > make the most sense is using the "best representation of the global > > > date and time string" and equivalents for just time and date that > > > have to be defined. Still, I'm not sure this is very useful, as the > > > same rendering (but slightly more flexible) could be accomplished by > > > simply putting the date/time in the content instead of in the > > > attribute. As a bonus, that would degrade gracefully. Unless I'm > > > missing something, I suggest dropping the special rendering > > > requirements for completely. > > > > The idea is to render the date or time in the user's locale, not the > > page's, though I agree that in some cases that could be confusing. > > > > Maybe we should leave the localising behaviour to author CSS and not > > do it automatically by default? > > I think that would be better, yes. Either that or a spec saying exactly > what string to output for each possible locale. (Making it platform- and > browser-dependent is just asking for trouble.) I haven't changed this at this point because it would leave the element as rendering nothing when the contents of the element are empty and the author has only provided an attribute. Most platforms have built-in mechanisms for showing dates and times in a fashion of the user's chosing. I suggest using that. It may be that this ends up being a lost cause, or that authors don't care about this, but I think we should at least give it a shot. I'm reluctant to have an element that does nothing visual and is just used for encoding data, since that is likely to end up with a lot more bogus data than if it actually does something. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element-related feedback
On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson wrote: This e-mail is a reply to a number of e-mails on various topics relating to the more document-related elements of HTML. On Mon, 16 Nov 2009, Philip Jägenstedt wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0 "When the time binding applies to a time element, the element is expected to render as if it contained text conveying the date (if known), time (if known), and time-zone offset (if known) represented by the element, in the fashion most convenient for the user." This is very vague. Anything which tries to localize the date/time will fail because guessing the language of web pages is hard. Hard-coding it to English also wouldn't be very nice. What seems to make the most sense is using the "best representation of the global date and time string" and equivalents for just time and date that have to be defined. Still, I'm not sure this is very useful, as the same rendering (but slightly more flexible) could be accomplished by simply putting the date/time in the content instead of in the attribute. As a bonus, that would degrade gracefully. Unless I'm missing something, I suggest dropping the special rendering requirements for completely. The idea is to render the date or time in the user's locale, not the page's, though I agree that in some cases that could be confusing. Maybe we should leave the localising behaviour to author CSS and not do it automatically by default? I think that would be better, yes. Either that or a spec saying exactly what string to output for each possible locale. (Making it platform- and browser-dependent is just asking for trouble.) -- Philip Jägenstedt Core Developer Opera Software
