- From: Sander Tekelenburg <st@isoc.nl>
- Date: Sun, 1 Apr 2007 19:16:12 +0100
- To: <whatwg@lists.whatwg.org>, <public-html@w3.org>
At 03:38 +0200 UTC, on 2007-04-01, Asbjørn Ulsberg wrote: [...] > While I'm a strong believer of separation between > structure (HTML), presentation (CSS) and functionality (JavaScript), I > think it could be useful for the HTML specification to -- within limits -- > define how each and every element's default CSS properties and values > should be like. > > This could improve interoperability in the presentation layer, since no > author starts with a blank canvas when composing his style sheet. FWIW, the WRI requires AWPSs[*] that generate CSS to include a 'CSS zapper': <http://webrepair.org/02strategy/02certification/01requirements.php#req26>. What would your proposal achieve that an author provided 'CSS zapper' does not? I can think of a few downsides: - The ideal presentation of something cannot be defined universally. What works well in one browsing environment doesn't necessarily work well in another. - It takes ages to define and implement a spec. Leaving UAs no room to in the mean time improve their built-in Style Sheets will slow down development. - Built-in Style Sheets leave UAs room to distinguish themselves from their competitors and can thus be an incentive to innovate, which can in turn make all UAs grow towards more maturity. - The user may well have changed the built-in Style Sheet to some other default, so authors won't be able to rely on a certain default presentation anyway. Why should these downsides be acceptable? Leaving aside whether the objective is desirable, I doubt this could even ever result in the objective. Even if HTML would spec a default presentation for everything, then still authors can not rely on every browser actually implementing that. So they'd still need to use a 'CSS zapper'. Frankly, I can't even imagine that we'd be able to agree on a default presentation for everything. So I suspect that at best this could result in an incomplete list of default styles, which would mean authors would have to provide a 'CSS zapper'. The fact that you already say "within limits" (what limits exactly?) and "informal" (in the Subject) mean suggests you are aware of these issues. At 12:28 +1000 UTC, on 2007-04-01, Lachlan Hunt wrote: [...] > Yes, that will be defined in due course. > > http://www.whatwg.org/specs/web-apps/current-work/#rendering That saying "when scrolling a page to a fragment identifier, align the top of the viewport with the target element's top border edge", seems to emphasize my argument. This is a silly requirement. When the anchor is near the end of the document, it would result in empty space below the document (what should happen with bottom fixed positioned content?). I doubt users and Web publishers would appreciate that and that UA authors would implement that. What instead this should say is something like "When taken to a fragment identifier, UAs must clearly indicate the referenced point in the content to the user". Because that *clarity* is what counts, not *how* that clarity is provided. For example, a UA could indicate the target by hiliting it for a couple of seconds, as iCab does. To me, as a user, that's a way more useful and elegant solution. Similarly, it would make sense for the spec to say that "by default, occurences of title attributes must be clearly indicated to the user", and "occurences of LINK elements must be clearly indicated to the user". But not *how* they should be indicated. Who are we (as spec definers) to decide that x is the only correct behaviour or presentation? And why should we want to stifle innovation by requiring some specific presentation? [*] Automated Web Publishing Systems. -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Sunday, 1 April 2007 17:22:35 UTC