https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #56 from S. McCandlish <[email protected]> 2010-07-29 01:30:26 UTC --- Aryeh, in Comment #52: >> Definitely proper in HTML5 >> http://www.w3.org/TR/html-markup/address.html > > Nope, definitely improper, see above. It represents contact info for the > <body> or <article> it's in, not arbitrary contact info. You quoted too selectively. The rest of it is: "If an address element applies to a section of a document, then it represents contact information for that section only." I.e., the element (and I agree it's an odd one) represents attribution, not arbitrary contact information, but it's scope is actually undefined (it *defaults* to the whole document, but can be just a "section", and the interpretation of that term is left open). This was actually *less* clear in HTML 4.01, which to my eyes suggested that it was only good for whole-document attribution except maybe there was an exception, but what sort of exception wasn't clear. I think that those working on HTML5 are clarifying for the reality that "a web page" or "a document" in spec terms is, in "Web 2.0" days like these, often a conglomeration of a bunch of different and different kinds of content from all sorts of sources, such that "section"-based attribution is frequently necessary. Michael in Comment #53: > It's not as specific as one might want, since all contributors' addresses > are applied to the entire page body, rather than each to its own comment, > but that's a perfectly valid interpretation. From HTML5: I'd say it's more specific than many users of address would normally think of, since it associates content at a very detailed level with specific author contact information. And it's non-problematic, since each contribution can be considered a "section" for HTML5 spec purposes, for which the contribution's author's user talk page, as you note, really is the relevant (i.e., non-arbitrary) contact information. Unless I've missed something here. Aryeh in #52 again: > But in the end, probably almost no one will use > it correctly or incorrectly, so meh, whatever. I concede that possibility. :-) Aryeh in #52 again: >> I wonder it we could actually expect editors to not put quotation marks >> in manually, or have MW work around it if they do? Sounds problematic (and >> again a good reason to fork that one into its own bug number). > > The idea is that they'll be auto-added in CSS Right. I'm saying that the real-world implementation has been about half-and-half, and it's been my experience that many people aware of the element don't know it is supposed to (and fails to, in some browsers) auto-generate the quotation marks (and specific types, based on language, nesting, etc.) I'd bet real money that over half of the people who attempt to use the q element put quotation marks just outside or inside it. So, implementing it might be (aside from better discussed in a new bug page) impractical until nothing but very obsolete browsers leave out the quotation marks, and users get used to the idea of not adding them manually. Christopher in Comment #54: > The text in question is a relative link that happens to be reflexive. The > engine detects that the link is reflexive so it renders the link as STRONG > (instead of A). I would say it could convert the first reflexive link in the > intro section of the article body to a DFN equally well, therefore allowing > DFN is not necessary for this use case. The advantage is that the link uses > wiki syntax, not HTML syntax. This presumes that all cases of a reflexive link are defining instances, which isn't true at all (I'd bet that in the Template namespace there are several thousand such links that are not defining instances, but simply part of misc. sentences in template documentation, because of widespread use of {{tl}}, {{tlx}}, etc. It would play havoc with transclusions, too. Basically, we cannot guarantee any connection between definingness of an instance and reflexive linking. We can't even 100% guarantee that bold stuff at or near the top of an article is a defining instance of a term (e.g. list articles often start with "This is a '''list of whatever'''", and "list of whatever" isn't a term we're defining. The term is "whatever", and it is defined not at this instance, but at the main article on the topic that the list is a [[WP:SUMMARY]] offshoot of. I can think of other issues, but the several already presented are enough to demonstrate that we cannot simply operator-overload the linking code to turn all reflexive links into dfn's. ABX in comment #55: > How would that work for wiktionaries, wikispecies, wikisources with OCR of > old encyclopedias and all other places where main definition is placed > differently than in pedia? It wouldn't. This is something that, like *almost* everything else in Wiki, actually needs human judgment applied to it and is best handled with a template. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
