Right now in wide usage on wiki markup like so is used: {| |- |valign=top width=100%| |}
The bgcolor, cellpadding, cellspacing, valign, align, width, height, etc... presentational attributes have all been completely removed from html5 and pages using these attributes aren't valid.
There's no way we'll expect all the instances of valign and width to disappear from every wiki on their own. And frankly in the context of authoring WikiText I don't believe the user should have to care about that and be forced to write a longer style line.
What are people's opinions on the idea of taking these removed presentational attributes, and turning them into sugared parts of WikiText that are output as actual css in the output.
The change would essentially mean that this: |valign=top width=100%| Would become: <td style="vertical-align: top; width: 100%;"> Instead of this: <td valign="top" width="100%">
I can only find one downside. Text browsers like w3m do make use of valign but don't support css, hence the change does make the valign revert to normal vertically centered alignment. I should make a few notes: - This doesn't even affect all text browsers. lynx doesn't display tables in a tabular form and hence doesn't care what type of alignment attributes you have. - This has absolutely nothing to do with web accessibility; Screen readers output to things like audio and braille, and hence don't display things visually so alignment means nothing to them. And w3 appears to restrict users with poor eyesight to proper css capable browsers. Standards for web accessibility for users with poor eyesight seams focused on things like ensuring usability with screen zooms and larger fonts, rather than expecting users with bad eyesight to use text browsers.
On 11.08.2011 11:39, Daniel Friesen wrote:
What are people's opinions on the idea of taking these removed presentational attributes, and turning them into sugared parts of WikiText that are output as actual css in the output.
The change would essentially mean that this: |valign=top width=100%| Would become:
<td style="vertical-align: top; width: 100%;"> Instead of this: <td valign="top" width="100%">
This sounds good to me.
I'd like to take this opportunity to once more float the idea of having two types of "tables" in wikitext:
* "grids" used for layout, that can be nested, and may be rendered as html tables but would better be rendered using divs with appropriate styles.
* actual data tables, which can not contain block elements in their cells (and can not be nested), for actual tabular data.
i think this would make for cleaner wiki text and for cleaner html output.
-- daniel
On Thu, Aug 11, 2011 at 2:39 AM, Daniel Friesen lists@nadir-seen-fire.comwrote:
What are people's opinions on the idea of taking these removed presentational attributes, and turning them into sugared parts of WikiText that are output as actual css in the output.
The change would essentially mean that this: |valign=top width=100%| Would become:
<td style="vertical-align: top; width: 100%;"> Instead of this: <td valign="top" width="100%">
That's basically what I've advocated for the last 7 years or so about what we'd do if/when that crazy "HTML 4 Strict" or "XHTML 1 Strict" or god forbid "XHTML 2" came along and actually mattered to anything for any purpose...
I'm not entirely convinced it's necessary at this stage though; HTML 5 draft spec has some wishy-washy language about "obsolete non-conforming features" that authors "must not use"[1], but I'd be a bit surprised if browsers are actually dropping support for <font> or @valign.
If it's just about feeling good when you run through a validator tool, a smarter validator tool that looks for things that are *actually* problems might be better to use. :)
Would anybody care to do some tests to confirm what the actual state of things is?
That said they're mostly trivial mechanical transformations, which both shows it'd be easy to do and proves how unnecessary it is to actually do the conversions.
[1] http://dev.w3.org/html5/spec/obsolete.html#obsolete
I can only find one downside. Text browsers like w3m do make use of
valign but don't support css, hence the change does make the valign revert to normal vertically centered alignment.
Note that that's the fault of using an old unmaintained browser: other text browsers like elinks understand at least some CSS (though none of lynx, elinks, nor w3m understood vertical-align: top on a table cell in a quick local test).
Simple fact is nobody seems to care about text-mode browsers enough to make one that actually works with the modern web (which is a very CSS & JS-heavy world if you go anywhere beyond just reading text); they're just old leftovers that a few geeks occasionally whip out for fun.
- This has absolutely nothing to do with web accessibility; Screen
readers output to things like audio and braille, and hence don't display things visually so alignment means nothing to them.
And more importantly, *screen readers hook into real modern browsers, which understand things like CSS and JS*. Nobody should assume that how things render in crappy old 'lynx' has anything to do with how a blind user with a screen reader will experience a page -- we need some actual accessibility-oriented folks to do testing with actual tools for that.
-- brion
On Tue, Aug 16, 2011 at 7:56 PM, Brion Vibber brion@pobox.com wrote:
I'm not entirely convinced it's necessary at this stage though; HTML 5 draft spec has some wishy-washy language about "obsolete non-conforming features" that authors "must not use"[1], but I'd be a bit surprised if browsers are actually dropping support for <font> or @valign.
The language isn't wishy-washy -- it's an authoring conformance requirement. The full explanation is here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.h...
The upshot is that HTML5 specifies what validators have to say is valid or invalid, and also how browsers have to process content, but the two are in general totally unrelated. Thus <font> is considered an error, but error handling is fully defined, so in practice it will work fine anyway except that the page won't validate.
If it's just about feeling good when you run through a validator tool, a smarter validator tool that looks for things that are *actually* problems might be better to use. :)
I've tried to argue that, but the editor disagrees and I eventually gave up. It might help if major software projects like MediaWiki officially said that they're not interested in validating as HTML5 because of this.
Would anybody care to do some tests to confirm what the actual state of things is?
Probably easier to just ask me. :) Web standards are my job these days.
That said they're mostly trivial mechanical transformations, which both shows it'd be easy to do and proves how unnecessary it is to actually do the conversions.
. . . mostly. There are actually a significant number of cases that aren't. Most of the table attributes (cellspacing cellpadding etc.) are very nontrivial. There's no precise CSS equivalent for <font size=7>. Parsing of <font color> is outright pathological, and doesn't map to CSS' color property at all:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsynt...
The align attribute and <center> have very particular effects that don't map to anything in CSS -- look at something like <div align=right><div style="width: 3em; border: 1px solid black">foo</div></div>, and try to change attributes on the outer <div> so it actually looks the same using pure CSS.
Etc. Some of these differences are not so important, but actually some of them are and will definitely break pages if you try rewriting stuff. A lot of this stuff uses pre-CSS parsing/rendering models that don't map cleanly to anything in CSS.
On Wed, Aug 17, 2011 at 9:56 AM, Brion Vibber brion@pobox.com wrote:
Note that that's the fault of using an old unmaintained browser: other text browsers like elinks understand at least some CSS (though none of lynx, elinks, nor w3m understood vertical-align: top on a table cell in a quick local test).
Simple fact is nobody seems to care about text-mode browsers enough to make one that actually works with the modern web (which is a very CSS & JS-heavy world if you go anywhere beyond just reading text); they're just old leftovers that a few geeks occasionally whip out for fun.
We should probably get around to writing proper browser compatibility guidelines for text browsers other than basically "it should still look some what sane, but may have some function" which iirc is what our current comp. guidelines say, and clearly spell out what functionality we can lose and/or degrade, how it has to layout etc.
wikitech-l@lists.wikimedia.org