- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 9 Jun 2009 12:20:17 +0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: HTML WG <public-html@w3.org>
On Jun 8, 2009, at 10:45, Ian Hickson wrote: > On Mon, 8 Jun 2009, Henri Sivonen wrote: >> On Jun 6, 2009, at 00:45, Ian Hickson wrote: >>> On Fri, 1 May 2009, Henri Sivonen wrote: >>>> >>>> So if I want to have a relatively simple GUI table editor that can >>>> read back what it has written but doesn't allow arbitrary styling >>>> to >>>> avoid breaking the consistent design of the site, I have to not >>>> only >>>> parse style='' values but parse arbitrary CSS and resolve class >>>> selectors? >>>> >>>> My concern isn't authoring in a text editor. >>> >>> In a graphical editor all you would have to do is use unique class >>> names (like com.example.numeric) and just ensure that those classes >>> have the appropriate style in the style sheet. >> >> Seriously? When there's already widely interoperable specific >> attributes >> for this? > > You are wildly oversimplifying "this". In practice a WYSIWYG tool > isn't going to style a table in 90% CSS and then gain great benefits > by > specifying just the vertical and horizontal alignment using > attributes, The use case I put forward wasn't in the context of an overall WYSIWYG design tool but in the context of a GUI tool that allows users input content but not tweak style. > _especially_ considering that those attributes don't even provide > the actual desired control (decimal alignment). Aligning stuff right is a passable substitute in the absence of decimal alignment. Most fonts have monospaced digits, so you get decimal alignment simply by having a fixed number of digits to the right of the decimal point. > Styling a table involves complicated rules for getting the borders > right, involves non-trivial padding even after getting the alignment > right, It seems very rare to tweak the padding on data tables on a per-cell basis instead of delegating it to a table-wide (or site-wide) style. > can involve per-cell colouring, etc. bgcolor :-) > At the end of the day, using the align="" and valign="" attributes > to control alignment on cells is a false economy. I disagree about align. It's by far the most common table formatting characteristics that the person managing the data in the cells would set even if the overall visual appearance is controlled by another person. > This is made significantly worse by the cost of including these > attributes in the language, which is a serious hit to the > credibility of argument that authors should separate their styles > and semantics for improved accessibility, maintainability, and > device-independence. You invoke a PR credibility issue. Isn't there a double-standard here? You are taking PR credibility risks when insisting on examining if @summary and @longdesc actually solve the problemes they are supposed to solve. Shouldn't we be scientific here and ask if making align='' non-conforming actually improves accessibility, maintainability or device-independence? How does class=com.example.numeric (a class name that client software knows nothing about semantically) with a style sheet improve accessibility compared to align=right? How does it improve maintainability? What about device-independence? > I firmly believe that a big part of why HTML4 failed to wean people > from Transitional is that it (even in Strict mode) gave credence to > the idea that presenational markup was ok. Or maybe the separation of structure and style emperor isn't fully clothed when taken to limit and having some presentational stuff in HTML doesn't lead to doom and gloom but is more practical to authors than maintaining a full separation. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 9 June 2009 09:20:57 UTC