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 mark. 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 Tue, 16 Mar 2010, Philip Jägenstedt wrote: On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson i...@hixie.ch 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 time 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 Fri, Jul 23, 2010 at 11:54 AM, Ian Hickson i...@hixie.ch 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
[whatwg] Element-related feedback; attribution element
In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025549.html with a subject of Element-related feedback, Ian Hixie quoted me and asked: On Fri, 1 Jan 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. Hixie: 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. 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. 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. You're still not saying why you want this element. What would attrib be good for? What UI would it trigger? How would users or authors benefit? (Per above, the UI would change voices in a screen reader, and could be used as a hook for user style sheets in scripts.) I would expect it to be used in License checkers that some organizations would deploy to ensure they aren't violating copyright. Wouldn't the Work microdata vocabulary be a better solution to this problem? Possibly. I find that more complicated, but the precision may be worth the complication. 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. I would expect it to be used with custom CSS for some users, who are really looking for a model or photographer rather than an existing photograph. I don't understand this case. Can you elaborate? Maybe an example of this use in the wild would help. Some of the original cite examples from the wild were really credits -- they listed the photographer and the model. 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. [On why cite should really be read as title_of_work, but still called cite for historical reasons] Why would it be wrong to have an element to style titles [for titles of works]? Turning around your favorite question, what is the semantic value? It provides a way to have appropriate default styling (italics, in the visual medium) for a typographic feature that is widely used, while allowing it to be easily restyled independent of other uses of italics. This is the same benefit em, strong, mark, etc, have. I think title of work is itself a fairly rare case. Normally, it is enough to just put it in quotes or italics. The times when you care that it is a title aren't really more common than the times that you care about attribution. -jJ
[whatwg] Element-related feedback
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, 2 Nov 2009, Elizabeth Castro wrote: In 4.4.11, it says Sectioning content elements are always considered subsections of their nearest ancestor element of sectioning content, regardless of what implied sections other headings may have created. Does that line mean that a section element is *not* a subsection of the nearest implied section? Correct. So, if there is no other explicit sectioning content, as in the example given, then what would the section element be a subsection of? Hm, yes, this was unclear. I've tried to clarify it. I don't get why Thud ends up on an equal level as Quux and Bar. It seems like as a section under h2 it should be a subsection of that Quux h2, just as the implied Bar section is a subsection of the implied Foo section. The body in that example counts as sectioning content. This was not stated in the spec previously. I've now made this clear. Thanks for catching this. On Tue, 3 Nov 2009, tjeddo wrote: What if a standard link type called citation was added to the HTML5 specification? For example, a href=#bibentry-jones rel=citation[Jones, p. 88]/a After reviewing all the other link types and their corresponding definitions in current draft specification this seems like a consistent addition. I recommend adding it to the wiki and then working to get it widely adopted. You don't have to depend on the spec for rel values, they registry is a publicly editable wiki. :-) On Fri, 1 Jan 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. 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.) You're still not saying why you want this element. What would attrib be good for? What UI would it trigger? How would users or authors benefit? I would expect it to be used in License checkers that some organizations would deploy to ensure they aren't violating copyright. Wouldn't the Work microdata vocabulary be a better solution to this problem? 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 would expect it to be used with custom CSS for some users, who are really looking for a model or photographer rather than an existing photograph. I don't understand this case. Can you elaborate? Maybe an example of this use in the wild would help. Why would it be wrong to have an element to style titles [for titles of works]? Turning around your favorite question, what is the semantic value? It provides a way to have appropriate default styling (italics, in the visual medium) for a typographic feature that is widely used, while allowing it to be easily restyled independent of other uses of italics. This is the same benefit em, strong, mark, etc, have. On Thu, 5 Nov 2009, Brian Blakely wrote: I can only imagine the usage of address/ will be utilized more productively if its intuitive purpose (arbitrary contact/postal addresses) were its actual function. As our friends at HTML5 Doctor illustrate, it is all too easy to jump to conclusions and use this element incorrectly. Perhaps a contact/ element would be more suitable for document-specific contact info? Just a thought, off-hand. In general, I agree. I seem to recall we studied this a few years ago and found that it turns out address is actually used correctly (per HTML4) quite a lot (especially in autogenerated documentation pages), which is why we left it as is. On Mon, 16 Nov 2009, Philip Jägenstedt wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component Is there a use case for machine-readable dates after ? I'm sure HTML5 will have been obsoleted before it's meaningful to express accurate times that far in the future.
Re: [whatwg] Element-related feedback
On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson i...@hixie.ch 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 time 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
