https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #43 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-07-22 17:24:10 UTC --- (In reply to comment #41) > The lack of the dfn element is a particular thorn in my side on Wikipedia > right > now, in reality and not in theory, as WP and other MW-based wikis > *overwhelmingly abuse* the dl/dt/dd elements all over the place (e.g. every > talk page!) for purely visual indentation (:) and/or boldfacing (;). A new > Bugzilla ticket (if one doesn't exist for this yet) needs to be opened to fix > this - replace all dl/dt/dd output of ":" and ";" wikimarkup with CSS-styled > divs. The only way to distinguish a real definition (e.g. in a glossary, > in-article or as a stand-alone list article) at the Web semantics level (see > below for numerous reasons this is useful and important) from misuse of these > elements, is with the dfn element. See draft guideline at [[WP:GLOSSARY]], > and > its geeky-as-heck subpage for some detail on MW/WP evilbadness when it comes > to > definition and more general lists. For more background on the dfn element and > its stable HTML 5 future, see the > http://www.w3.org/TR/html5/text-level-semantics.html#the-dfn-element page. > > That said (i.e. my personal reason for stumping for dfn), the dfn element is > also very useful all over Wikipedia and similar sites just by the element's > very nature. It should be one of the most-used. For example, I think that on > Wikipedia in particular, the bold-faced beginning of lead sections in > mainspace > articles should mostly be done with a template that auto-adds dfn, instead of > manual boldfacing, e.g.: "An {{leadterm|electrokardiogram}} is..." I mean, > really, that's precisely what this element exists for: To flag the defining > instance (in its context) of a term. The average human reader looking (i.e. > with working eyes in a typical browser) at a WP article might not experience > anything differently, but it has a lot of automated processing potential, and > accessibility improvement potential, especially in articles that present > several closely-related things in one article (e.g. submodels or "trim levels" > of a car, e.g. the GT Cruiser and Street Cruiser variants of the PT Cruiser). > With dfn support, users of text-to-speech screen readers would be able to > customize their style sheets to do something specific for dfn-flagged > "defining > instances" to help distinguish them from "just another section" and "just > another boldfaced something". > > I don't recall making any search-engine-related argument about dfn, though > there may well be one. And an argument like "we shouldn't implement it > because > search engines don't use it" (which I'm not sure was being made here, but it > kind of looked like it) is logically invalid anyway, since there may be many > other things/people that do/will use the feature under discussion for various > reasons and purposes (not to mention that it's tautological and circular - a > search engine can't use a wiki feature that isn't implemented, by definition, > ero the lack of evidence of the search engine using the feature on wikis > cannot > be used as an argument against the feature's wiki implementation, obviously - > it puts the cart before the horse). So what you're saying is that theoretically someone somewhere might be able to derive some benefit from this, but you don't have specific examples of people who *will* benefit from it? Like who have said they want it and will use it for some specific constructive purpose if it's available? Maybe we should allow it even if it's only useful in theory, but if there were real-world uses (i.e., non-hypothetical) then I'd certainly be fine with adding it. I'd like to be clear one way or the other on that. (In contrast, I think <address> certainly should not be added under any circumstances, and have *very* strong doubts about <kbd> and <samp> given their incredibly limited utility.) > Putting the address element back in since I and whoever first proposed adding > support for it, probably among others above, obviously do support adding it. > The address element isn't deprecated in HTML 5 > (http://www.w3.org/TR/html5/sections.html#the-address-element), so DO include > it. It serves a well-defined semantic purpose just like every other > non-presentational element. It IS actually particularly useful on wikis (not > necessarily WikiPEDIA, mind you, but keep in mind that MW software can be used > for an endless number of end purposes, including databases of contact > information, etc.) when integrating metadata inline in the content with id= > and > a standardized metadata schema like hCard/vCard. It should be in the MW > software, and it should be up to individual installations' system operators > whether to turn that element off. The address element gives contact information for the author of the page. Since wiki pages are, by their nature, not owned by anyone or authored by any single person, it makes no sense for wikis. If someone really wants to abuse MediaWiki as a CMS, and really wants to use <address>, they can hack it into Sanitizer.php. Or ask for it to be optionally (non-default) whitelisted. It makes no sense in normal wiki pages, though, and should not be allowed by default. > You seem to be ignoring the nature of [X]HTML and Web semantics. *These tags > actually mean something* and they all mean something *different*. Nothing > could > be further from the truth than them being "basically useless" (or they > wouldn't > have been carefully preserved in HTML 5 and even better explained there than > in > HTML 4 and earlier). It actually blew me away for a while when I tried to use > these as intended, in template documentation, and they didn't work. Disabling > them was pointless and a bad idea. You seem to me to be approaching this from > a 1995 browserwars-era, HTML 3-ish "if it LOOKS right, it IS right" Web dev > paradigm that is long obsolete and which generates genuine problems for many > people on both sides of the user/provider Web equation. It's ultimately > irrelevant that your particular browser, and even Wikpedia's style sheets, may > choose to *style* these tags the same, visually (monospaced, non-proportional > font), and they thus *appear* redundant to you. *The are not the same*. User > keyboard input (kbd element) is not output (samp element) is not source code > (code element) is not a variable (var element) and so forth. Any user of a > modern browser is free to override the default style sheets they receive from > WP or any other site and from their browser, there is no guarantee that every > visual browser does and forever will style these elements all the same by > default, there no guarantee that even Wikipedia will always style them the > same > (esp. given the weirdness that WP does in CSS to many things, including the > pre > element), there's a near certainty that some screen readers do not treat them > as identical by default, and there's an absolute certainty that power users of > good screen readers customize their style sheets to not treat them as > identical. I'd like to see specific examples of screen readers or power-users' stylesheets that do not treat these the same as <code> or <tt>, since you say these are near certain or absolutely certain. Semantic distinctions need only be drawn where they're concretely useful. Otherwise you could spend all day marking things up for some hypothetical consumer who will probably never exist. If you have no specific examples of nontrivial numbers of users who you can *demonstrate* (not conjecture) will actually make use of the distinction, it is not worth the added language complexity. I will particularly point out that wikitext is not HTML, and wikitext is not intended to produce all valid HTML. Just because someone at some point in the distant past in HTML's development thought that these distinctions might be worth making in HTML, doesn't mean that wikitext has to agree. > There's no evidence I'm aware of that they confuse people. If they did, they > would no longer be part of the [X]HTML specs, given that there's been all of > the 1990s and 2000s to get rid of them if they were actually problematic. > Mostly only HTML-experienced editors do anything with HTML elements manually > on > Wikipedia anyway, and they are the least likely to be confused. If some dwid > does muck something up, someone with more know-how will fix it, just like > everything else on Wiki (which is chock full of much, much more confusing > things that a couple of HTML elements). HTML elements are mostly used in > templates, which again are usually created by savvy editors who know the > difference between one element and another. The "confusing" argument is > therefore unconvincing. One of the goals of wikitext is to minimize the amount of actual HTML in markup, to make the code less intimidating to non-techy types. By their nature, <dfn> <samp> and <kbd> will be used in actual article text if they're used at all -- they can't be hidden away in the depths of templates in most cases. More and different HTML tags in wikitext works against the original purpose of wikitext. The people who *add* it might know what it means, but the people who have to *read* it (other editors) might not. HTML is, again, different from wikitext. Wikitext does not aim to allow users to produce all possible HTML. HTML5 has elected to keep these elements because they're fairly harmless and it doesn't want to force people to change their preexisting valid pages needlessly. I actually filed a bug against HTML5 suggesting <samp> and <kbd> be removed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9919 It will probably be resolved within a few months, one way or the other. > So, to answer your "the question", it is *automatically and by definition* > "more useful" to use the proper elements for the content that is appropriate > for them, than to continue to abuse the code and (worse yet) tt elements, just > like it is automatically and by definition more useful to use a screwdriver > than a hammer when dealing with screws instead of nails, regardless of the > fact > that a sufficient application of force with a hammer can drive a screw into > wood as if it were a nail. Use the right tool for the job, and you have > smoother work, a happier worker, and better work output. In other words, you cannot present any specific practical benefit to allowing these elements, it just makes us More Semantic and this is obviously good? I don't find this argument convincing. > "A wiki" can't make a request; editors on/of a wiki make requests. I meant that there could be an on-wiki discussion that reached consensus to ask the developers to make a change. I really doubt such a thing would happen for <q>, but if it did, it would be relevant. > IMPORTANT: After this bug is resolved (and finish reading to see why it *must* > be), there will ultimately need to a be a new bug report here, to get rid of > support for the tt element entirely, which doesn't exist in HTML 5. Here's a > good discussion of this issue (more broadly than wiki), and Googling about it > turns up more: > http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2009-April/000233.html <tt> exists in HTML5. It's just classified as obsolete presentational markup, and is not valid: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#tt The same is true for loads of other things that we allow. We cannot remove support for these from MediaWiki without a migration path to convert all existing markup somehow. But this is a totally separate bug. > PS: If we put angle brackets around the element names in these discussions, > many mail systems that try to parse [X]HTML on the fly in e-mail regardless of > its MIME type will interpret them as markup and not render them as text. I.e. > "since the <blockquote> tag is already..." renders as "since the tag is > already...", with everything after "the" indented (sorry, some of you won't be > able to read that properly; the example passage has a blockquote tag in it). > This makes the messages basically impossible to correctly parse without coming > to bugzilla.wikimedia.org to read them. I've refactored the quoted material in > this message to compensate (e.g. I used "the blockquote tag", etc.). If your mail client touches angle brackets in plaintext e-mails, it is absolutely and completely broken and you need to tell it to stop. E-mail supports MIME types and your client needs to respect them. It's part of the SMTP standards and everything: <http://tools.ietf.org/html/rfc1652>. Surely you're not saying I should write my Bugzilla posts to work around broken tools that don't obey standards? 0:) -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
