Re: FAQ about reasons behind CSS

Mikko Rantalainen schreef:
> I scanned the FAQ briefly and I noticed that it uses a lot of 
> abbreviations (or acronyms...) without explaining those. For example:
[...]
> WD
> CR (granted, this is explained at the END of the document)

Those two should have <abbr> tags around them. I will take care of the rest.


> Remember that FAQs are most used by newcomers and they are not familiar 
> with all the TLAs.

Well, it is not a FAQ for ‘real’ beginners (some knowledge is expected, 
but ok) (TLA? heh :)).


> If this is supposed to be THE CSS FAQ, it would be better to explain 
> basic stuff like inheritance and box model before explaining the more 
> complex issues.

No, it has nothing to do with that. I should rename it I guess, to ‘The 
reasons behind CSS FAQ’ or something.


> Also, the FAQ takes it as given that there's following constraint for CSS:
> 
>   "Incremental rendering (no reflow)"
> 
> I don't agree with this. CSS already has ::nth-last-child(), among other 
> things, which cannot be used with incremental rendering.

Will rephrase to ‘avoid’.

I think that ::nth-last-child() should have never been added, it’s not 
very useful anyway :).


> I cannot agree with a view that some layouts should be forbidden because 
> they cannot be achieved with incremental rendering.

Sorry, I did not mean to express such a view, I will see if I can 
rephrase things. It is however one of the starting points of CSS, and 
things are designed to allow for incremental rendering as much as 
feasible, and if they do cause reflows, as few and as little intrusive 
as possible.

In CSS3 things are introduced which break incremental rendering, like 
::nth-last-child(), so it is not a ‘sacred’ rule in any way.


> The CSS 
> specification could do better job pointing out which features do mess up 
> the incremental rendering, though. If style author (as opposed to 
> content author) decides to sacrifice rendering speed for nicer final 
> result, who am I to tell otherwise?

Agreed, absolutely. See this recent post of mine: 
http://lists.w3.org/Archives/Public/www-style/2005Jun/0085


> Do you really think that CSS should never ever provide a way to 
> automatically generate TOC because that would require looking forward in 
> the document if the TOC were to be placed before the content? Is TOC 
> really part of the content or is it part of the presentation?

Yes, I do think so. TOC is part of the document.

Especially considering that usually a TOC also has links in it, should 
CSS take care of that as well? Etc. It’s definitely outside the domain 
of CSS, authoring or server-side tools should take care of that.


> In addition, some of the questions could be relabeled to better match 
> the answer. For example, instead of
> 
> "Q: How long does it take for new CSS features to be available"
> 
> following would match the given answer much better
> 
> "Q: Why shouldn't I start using a new CSS feature immediately after it 
> has been invented?"
> 
> [IMO the new feature is available immediately after it has been 
> implemented in *some* UA. There're practical reasons to wait for broader 
> support, though.]

I will take a careful look at the questions. In this particular case, I 
plan to add a paragraph addressing that. (Note: you only eliminate user 
adoption time, and not the other ones.)


> As a whole, it seems that this FAQ mixes the practical view (MSIE has 
> abysmal support for CSS) with the specification and claims that the CSS 
> (specification) as a whole doesn't support layout, tables and what-not.

Such a claim is unintentional, that is an error.

Nevertheless, the mix of practical and spec is intentional, because 
people are always looking at real-world cases, and it will hopefully 
help to illustrate the points.

Thanks for the input! It is only a first version, and I’ll be sure to 
update it :).


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!

Received on Thursday, 30 June 2005 11:00:09 UTC