- From: Sander Tekelenburg <st@isoc.nl>
- Date: Fri, 25 May 2007 02:06:56 +0200
At 18:43 +0000 UTC, on 2007-05-24, Ian Hickson wrote: [...] > It's been considered and might even happen. It's a MASSIVE amount of work, > though. For example, it's also not always clear how to categorise the > text. What would you do with: > > <p>If a <code>dl</code> element contains only <code>dd</code> > elements, then it consists of one group with values but no names, > and the document is non-conforming.</p> > > Should that be shown in the cut down "author" version? Yes. Everything that tells authors how to ensure conformity should be presented to them. I think it's mainly the stuff that tells UAs how to handle non-conforming documents that authors generally don't need. > There are also a number of sentences that would need to be rewritten so > they still make sense with parts of the sentences hidden. Can you point to an example of where you think this would be necessary? My impression was that we're talking mostly about blocklevel content -- hiding paragraphs or even sections. If it would be necessary to mark sentences, or even parts thereof, and to rewrite content, then indeed that would be a hell of a job. But even then I think it would already be a huge improvement if that content were left as it is for now, and to begin with marking only block level stuff that can easily be identified as 'obviously relevant to UA implementoirs only'. Btw, by taking the CSS approach (one spec; different presentations), during the spec's development you could use a Style Sheet that merely sets content apart, not outright hide it. Just like Simon did. It seems likely to me that, because that makes this so visible, people will provide plenty of feedback when something should be shown to/hidden from authors. I don't think this needs to be pixel-perfect, definitely not from the start. Begin by marking what is obviously not needed by authors. From there it will get clear how much more detailed this should be done, if it all. -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 24 May 2007 17:06:56 UTC